Hmm, ik heb ook een tijdje Experiaboxen gebruikt (tot ik een manier vond om er vanaf te raken icm. ADSL en glasvezel, gebruik toch geen telefonie) en mij viel eigenlijk nooit slechte performance op. Gewoon goed (100 mbit strak).
Overigens, in navolging van een paar posts van mij van een poos terug, m.b.t. de "Advanced Format" van -EARS schijven van Western Digital:
Ik heb gisteren er een 2 TB Schijf bij aangeschaft, namelijk de WD20EARS. Nadat ik al mijn data van m'n primaire disk (een 1,5 TB Samsung schijf) veilig had gesteld en m'n 2e disk eruit getrokken (een WD10EARS) heb ik de WD20EARS geinstalleerd als 2e schijf.
Daarna Factory Reset procedure uitgevoerd (op de achterkant de reset knop van m'n 209+II 4 sec. ingedrukt houden en daarna nog een keer 4 sec.).
Vervolgens met de nieuwste DS Assistant de laatste firmware er weer opgezet en daarna de WD20EARS geformatteerd. Tot m'n grote teleurstelling begon nog steeds de eerste partitie bij 63, ipv. 256. Wat me echter ook opviel was dat de factory reset procedure nog steeds de data op m'n eerste schijf had gespaard.
Hierop heb ik met het "dd" commando gewoon bruut beide schijven ongeldig gemaakt (gewoon van /dev/zero naar het device van de harddisk schrijven voor een paar seconden

). Daarna heb ik opnieuw een factory reset gedaan. En: BINGO!
Het lijkt er dus op dat, om een -EARS schijf herkend te krijgen, je ALLE schijven leeg moet maken, ookal is bv. je disk 1 een schijf van een ander type. Na deze totale her-initialisatie begint de eerste partitie netjes op 256. Het stomme is alleen dat dit bij m'n Samsung schijf nu ook zo is.
Maar goed, beide schijven hebben nu een acceptabele performance en ik meen ook een keer gelezen te hebben dat een "partitionering nieuwe stijl" voor een reguliere harddisk verder geen nadelen kent. In ieder geval doet de -EARS nu ook goed mee.
Samsung HD154UI
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| netdisk> fdisk -lu /dev/sda
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 256 4980735 2490240 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2 4980736 9175039 2097152 fd Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sda3 9437184 18446744072344847327 18446744073022480880 f Win95 Ext'd (LBA)
/dev/sda5 9453280 18446744072344847327 18446744073022472832 fd Linux raid autodetect |
WDC WD20EARS-00J2GB0
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| netdisk> fdisk -lu /dev/sdb
Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 256 4980735 2490240 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2 4980736 9175039 2097152 fd Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sdb3 9437184 18446744073321599327 18446744073510856880 f Win95 Ext'd (LBA)
/dev/sdb5 9453280 18446744073321599327 18446744073510848832 fd Linux raid autodetect |
De data van m'n WD10EARS, die ik later via een s-ata dock heb aangesloten, terug kopieren naar de NAS was trouwens nog een hele toer

. De schijf wordt niet automatisch herkend als zijnde een schijf die vroeger een geldige Synology-disk was, dus je moet nogal wat uithalen om 'm herkend te krijgen:
Hierbij overigens als aanname dat je de oude schijf via e-sata aansluit en hij zodoende "/dev/sdc" heet. De partitie waar ik m'n gegevens van wil halen is /dev/sdc5 (het data volume).
* Als eerste moet je met "mdadm --assemble /dev/md6 /dev/sdc5" weer een RAID-device aanmaken (let op dat je voor /dev/mdX iets kiest wat nog niet in gebruik is). In mijn geval was het gewoon een non-raid volume dat dus echter wel als een single-disk raid volume wordt aangemaakt en behandeld door de Synology firmware.
* De complicatie is dat er bovenop dit RAID volume een Physical volume voor LVM ligt. Synology doet dit tegenwoordig blijkbaar bij alle data volumes. Wat het nog vervelender maakt is dat de volumegroup op dat PV "vg1" of "vg2" heet. Echter, als je alweer de nodige volumes op je nieuwe schijven hebt, ontstaat er een volumegroupname conflict, omdat 1 van je bestaande volumes wrs. ook die naam heeft.
* Met "vgdisplay" kan je alle volumegroups weergeven, incl. de conflicterende. LVM maakt ook melding van deze conflicten. Als je een "lvm vgrename <uuid-van-oude-volumegroup> <willekeurigenieuwenaam>" geeft wordt het volumegroup ge-renamed. Een nieuwe "vgdisplay" zal dit bevestigen en de melding van het conflict zal verdwenen zijn.
* Je logical volume op de oude schijf is nu beschikbaar via "/dev/<willekeurigenieuwenaam>/lv". Met een "lvdisplay" zal je echter zien dat "LV status" op unavailable staat en je alsnog het filesystem op de LV niet kan mounten. Met een "vgchange -a y <willekeurigenieuwenaam>" komt hier verandering in. De volumegroup EN het LV is nu beschikbaar om gemount te worden en je kan je data terug kopieren.
Nog een laatste opletter:
* Het is schijnbaar moeilijk of onmogelijk (mij is het iig niet gelukt) om het RAID volume en Volumegroup van een door Synology ingedeelde schijf op een gewone PC met bv. Ubuntu te mounten

. Een "mdadm --assemble" geeft te kennen dat er geen RAID superblock aanwezig is. Ik had ergens anders gelezen dat dit veroorzaakt wordt doordat de processor architectuur van bv. een DS209+II een andere byteorder gebruikt (big-endian versus little-endian). Met een "--update byteorder" in het mdadm --assemble commando gevoegd zou dit opgelost moeten worden maar helaas, still no dice.
Op zich is dit wel verontrustend, omdat ik altijd in de veronderstelling was dat je een synology data volume gewoon met iedere willekeurige linux pc wel kan benaderen, mocht je Synology bv. stuk gaan ofzo.
[
Voor 29% gewijzigd door
eymey op 30-05-2010 13:19
]
Marstek Venus 5.12kWh v151, CT002 V118, CT003 V116 DSMR5.5, PV 11xEnphase IQ7+ Z-O, 5xEnphase IQ7+ N-W - ~4,7Wp theoretisch, ~3,5Wp praktijk.