Het grote DIY RAID NAS topic deel 3

[TrailBlazer]

Verwijderd schreef op maandag 25 juli 2011 @ 10:55:
[...]

4K sector hardeschijven zijn intern wel 4K sectors maar presenteren zich als 512-byte sectors en mocht je bijvoorbeeld I/O in non-4K veelvouden doen zoals 3.5K of 4.5K dan vindt er emulatie plaats. Behandel de disks voor alle partitie zooi dus gewoon als 512 bytes; daar werkt je OS namelijk mee.

Oh en als je ooit grotere schijven wilt dan 2TiB (3TB schijven bijvoorbeeld) dan kun je nu al overwegen om GPT partities te gebruiken want met 512-byte publieke sectorsize en MBR partities heb je maximaal 2TiB wat je kunt partitioneren. Je hebt GPT nodig om daar overheen te gaan.


[...]

2048 * 512-byte = 1MiB (de correcte Win7 alignment methode)
63 * 512-byte = 31.5KiB (de vieze XP alignment methode)

en (g)parted gaat uit van een sectorsize van 512bytes? Dus ik moet eigenlijk 8 keer zoveel sectoren alloceren als ik net had opgeschreven. Dit zou dan (2*10^12-100*10^6)/512= 3906054688 512bytes sectoren zijn.

parted /dev/sdX unit s mkpart primary 2048 3906054688

mdadm --create --verbose /dev/md0 --level=5 --mklabel gpt --raid-devices=3 /dev/sd[a-c]

Zover

iMars schreef op maandag 25 juli 2011 @ 10:58:
ik weet moet je gewoon de grootte opgeven (ik meen me iets te herinneren als 18.... nogwat 2TB is 1,8...TiB)

[...]

Ah dat verklaard een hoop

Ik specificeer sectoren dus dan moet ik naast de offset in sectoren ook de lengte in sectoren doen.

[matthijsln]

Alle huidige 2TB schijven van Seagate, Samsung, WD en Hitachi hebben evenveel 512-byte sectors: 3.907.029.168 met een capaciteit van 2.000.398.934.016 bytes (dus niet 2.000.000.000.000 bytes).

Dus 2TB schijven hoef je niet te onderpartitioneren voor het aanmaken van een raid-array.

[FireDrunk]

Dat is goed om te weten, hoeven we ons daar ook niet mee druk over te maken.

[TrailBlazer]

Ok maar moet ik dan nog wel de startsector specificeren?

[Verwijderd]

TrailBlazer schreef op maandag 25 juli 2011 @ 11:17:
[...]

en (g)parted gaat uit van een sectorsize van 512bytes?

gparted gebruikt wat je OS gebruikt; je OS ziet die schijven als 512-byte sectoren omdat ze zich als zodanig presenteren aan het OS. Er bestaan voor zover ik weet nog geen échte zogenaamde native 4K sector schijven, die ook daadwerkelijk 4K sectoren aan het OS/host presenteren. Voor die schijven is het onmogelijk om I/O te verrichten die niet in veelvouden van 4K blokken bestaat. 512-bytes schrijven naar zo'n schijf krijg je een I/O error terug. De sectorsize moet worden nageleefd. Om die reden om compatible te blijven met oudere OSen is voor een aanpak gekozen dat huidige 4K sector schijven emulatie toepassen en 512-byte sectoren presenteren; als een soort tussenstap alvorens er echte 4K sector schijven komen en de emulatie dus achterwege kan worden gelaten.

@matthijsln: klinkt plausibel en in lijn met de bevindingen van FireDrunk. Echter het reserveren van ruimte aan het einde van de capaciteit kan nuttig zijn om andere problemen te vermijden. Bijvoorbeeld:
1) de software 'dualBIOS' functie van Gigabyte die ruimte van je hardeschijf steelt om een backup van je BIOS te maken
2) FakeRAID zoals Silicon Image die de laatste 512-bytes overschrijft bij het booten voor de RAID configuratie; deze laatste sector mag je dus niet gebruiken. In sommige gevallen kan het ervoor zorgen dat je systeem niet meer boot.

Met dat laatste heb ik persoonlijke ervaring. Ik kies er dus altijd voor om ruimte te reserveren. Maar in elk geval is het goed te horen dat hardeschijffabrikanten kennelijk zo slim zijn om hun capaciteiten op elkaar af te stemmen.

[matthijsln]

Verwijderd schreef op maandag 25 juli 2011 @ 11:50:
[...]
@matthijsln: klinkt plausibel en in lijn met de bevindingen van FireDrunk. Echter het reserveren van ruimte aan het einde van de capaciteit kan nuttig zijn om andere problemen te vermijden. Bijvoorbeeld:

Klopt, en er is geen garantie dat bij een nieuw type of andere firmware het aantal sectors niet wijzigt, of dat het bij een 3TB schijf ook altijd zo is. Maar ik had dit uitgezocht voor het geval dat ik een 2TB schijf van mijn mdadm raid5 array zou moeten vervangen. Het is inderdaad niet zo dat je geen 100MB kan missen dus als je het zekere voor het onzekere wilt nemen kan je gewoon onderpartitioneren. Alhoewel je dan in plaats van 'fill entire disk' het aantal sectors moet uitrekenen

Daarnaast heb ik gewoon het OS op de raid-component disks staan in raid1 voor de raid data partitie in plaats van een losse schijf, dus ik kan op een eventuele vervangende schijf gewoon de swap partitie wat minder groot maken.

[TrailBlazer]

Waar zit trouwens de 1e sector van een harde schijf aan de binnen of buitenkant. Aan de buitenkant is de leessnelheid hoger maar seektime hoger aan de binnenkant juist andersom. Voor de capaciteit maakt het niet uit of je een of twee sets maakt maar je kan dan wel een snelle en tragge array maken.

[Verwijderd]

De capaciteit van een hardeschijf begint in de buitenste tracks; daar is de performance het hoogst. Het einde van de capaciteit zit aan de binnenste tracks waar de performance het laagst is. Dit kun je goed zien met een standaard HDTune benchmark; je begint op 140MB/s en eindigt op 65MB/s voor een moderne schijf.

[Sleepie]

iMars schreef op maandag 25 juli 2011 @ 10:37:
[...]

Tja, ik heb 4 van die samsungs en heb het zonder partities gedaan. In mijn geval:
mdadm --create --verbose /dev/md5 --level=5 --raid-devices=4 /dev/sd[c-f]

Dus in jouw geval zou ik het volgende doen:
mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sd[a-c]

Ga je ook boot-en vanaf je array? Of heb je een aparte bootdisk?

Als je met nieuwe schijven een nieuwe array gaat maken voeg dan de volgende optie toe:
mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 --assume-clean /dev/sd[a-c]

Dat scheelt je een initiele raid-rebuild

[matthijsln]

Sleepie schreef op maandag 25 juli 2011 @ 13:24:
[...]
Dat scheelt je een initiele raid-rebuild

Als je schijven nieuw zijn zorgt zo'n rebuild er wel voor dat je schijf alle sectors langsgaat om te lezen of schrijven, dus het is niet totaal zinloos omdat je je schijf er ook enigszins mee test, denk ik dan

[Verwijderd]

Als sectoren nog niet beschreven zijn is het onlogisch dat er van gelezen wordt. Het is dus niet erg als die sectoren hun magnetisme verliezen en dus kans hebben om onleesbaar te worden. Zodra ze gebruikt worden wordt er naar geschreven en dan heb je van dit probleem geen last meer.

Zo'n rebuild is dus handig voor hardeschijven waarvan de data er al een tijdje op staat en sommige data niet/nauwelijks gelezen wordt voor meerdere maanden of zelfs jaren. Dan is een rebuild om alles te lezen wel handig om zwakke sectoren op te sporen; die de schijf zelf zal vervangen voor reserve sectoren. Dit detecteren de hardeschijven intern door de tijd te meten die het duurt om de sector te lezen; als dat langer duurt dan normaal zullen ze zelf al uit voorzorg de sector omwisselen; om te voorkomen dat de sector in de toekomst helemaal onleesbaar wordt en er dus dataverlies optreedt. Dit proces is totaal transparant; je RAID layer merkt er niets van. Je ziet wel Reallocated Sector Count in je SMART output omhoog gaan.

[iMars]

Sleepie schreef op maandag 25 juli 2011 @ 13:24:
[...]

Als je met nieuwe schijven een nieuwe array gaat maken voeg dan de volgende optie toe:
mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 --assume-clean /dev/sd[a-c]

Dat scheelt je een initiele raid-rebuild

Ik bedoelde uiteraard ook de --assume-clean optie erin

[BlackShadow]

jimmy87 schreef op zondag 24 juli 2011 @ 22:41:
Met softraid werkt dat prima inderdaad. Met een hardware raid controller is dat wat anders. Wij hebben als bedrijf een tijd de WD20EARS gehad voor icm oa een P410 van HP. Doordat de schijf uitgaan na een tijd kan de raid controller ze niet detecteren en geeft deze ze inderdaad als failed aan. Dus wat wirehead zegt klopt wel hoor met hardware raid in ieder geval.

Ik heb sinds begin juni 3 WD20EARS draaien op een Adaptec 5805 controller in RAID5.
Nu heb ik hier nog geen enkel van de vermelde problemen opgemerkt, alles draait nu stabiel.

Ik heb er wat tijd laten over gaan wegens de negatieve berichten over de EARS icm HW raid controllers.

Nu zou ik toch graag jullie advies willen wat betreft de uitbreiding, mijn mogelijke opties zijn:
- De WD20EARS van de hand doen en Samsung F4's kopen voor de Adaptec 5805
- De RAID controller van de hand doen en software raid gaan doen (veel meer tips te vinden hier over soft icm EARS)
- Het risico nemen en toch WD20EARS bij kopen

Aangezien het om veel data gaat, zou ik toch graag een combinatie van betrouwbaar en betaalbaar behouden.

[Verwijderd]

*

[ Voor 100% gewijzigd door Verwijderd op 26-07-2011 20:18 ]

[Weiman]

Ik zit een beetje in hetzelfde bootje als Blackshadow, heb 5 1.5TB Samsung F3 Ecogreens in RAID 5 op een Promise EX8350. Draait nu een jaar met nul errors, maar raakt een beetje vol. Dezelfde schijven zijn bijna niet te krijgen, maar 1.5TB F4's hebben een prima prijs/GB. 3 erbij prikken en de array expanden is zo gepiept, maar tsja. Of dat goed blijft gaan...

[Verwijderd]

Weiman schreef op dinsdag 26 juli 2011 @ 20:21:
Ik zit een beetje in hetzelfde bootje als Blackshadow, heb 5 1.5TB Samsung F3 Ecogreens in RAID 5 op een Promise EX8350. Draait nu een jaar met nul errors, maar raakt een beetje vol. Dezelfde schijven zijn bijna niet te krijgen, maar 1.5TB F4's hebben een prima prijs/GB. 3 erbij prikken en de array expanden is zo gepiept, maar tsja. Of dat goed blijft gaan...

en een 2e array aanmaken met nieuwe schijven ?

[Weiman]

Dat is inderdaad het alternatief. 3 2TB disks in RAID5. met optie 1 krijg ik er 4.5TB bij, bij de ander 4TB. De een kost zo'n 150 euro, de ander 180, maar in principe minder kans op dataverlies

[Verwijderd]

Weiman schreef op dinsdag 26 juli 2011 @ 20:33:
Dat is inderdaad het alternatief. 3 2TB disks in RAID5. met optie 1 krijg ik er 4.5TB bij, bij de ander 4TB. De een kost zo'n 150 euro, de ander 180, maar in principe minder kans op dataverlies

een ander gevaar is dat je een 'oude' array gaat uitbreiden met nieuwe schijven.. vroeg of laat vallen toch oude schijven uit.

[FireDrunk]

Tjah, keuzes... Denk vooral op de lange termijn... Het is altijd leuk om op korte termijn veel te hebben, maar wat nou als het weer vol raakt? Plaats je dan nog een controller bij? Maar dan kan je dat raid volume weer niet extenden..

Wat dat betreft is software raid veel flexibeler. Of je nu op Intel of AMD draait, en zolang je maar een HBA gebruikt, maakt het allemaal niet uit...

[BlackShadow]

Bij mij is het niet perse het niet meer te verkrijgen, maar de vele slechte ervaringen met de WD's.

Ik denk dat ik gewoon maar alles vervang door Samsung F4's en de WD's van de hand doe...

[FireDrunk]

We kunnen ruilen voor een schappelijk bedrag

[TrailBlazer]

vanmorgen was mijn raid array klaar met builden en even een snel testje gedaan. Ik kwam uit op een schrijfsnelheid van 100 MByte/s (3x2 TB raid 5) Nu las ik opeens wat over de chunksize en dat dat nog wat kan schelen nu daar maar even over inlezen.

[Verwijderd]

De stripe cache size doet ook een hoop, da's ff pielen, maar probeer het maar eens met 4096

[BlackShadow]

FireDrunk schreef op woensdag 27 juli 2011 @ 08:11:
We kunnen ruilen voor een schappelijk bedrag

Ik vind het zonde omdat ik er tot nu toe geen problemen mee gehad heb.
Zijn er parameters die ik kan controleren die wijzen op fouten/incompatibel?


In hoeverre gaat TLER problemen geven bij de WD's?
Want in feite zijn de Samsung F4's ook gewoon consumenten schijven.
Is het risico met deze dan opvallend lager?

edit:
Zijn er bvb stress testen die de incompatibiliteit kunnen uitlokken?

[ Voor 19% gewijzigd door BlackShadow op 27-07-2011 11:16 ]

[FireDrunk]

Risico is even groot...

[HarmoniousVibe]

FireDrunk schreef op woensdag 27 juli 2011 @ 11:16:
Risico is even groot...

Kun je bij die Samsungs CCTL niet aanzetten? Dan is het risico minder groot. Kijk anders ook eens naar Hitachi's. Volgens mij kunnen die dat sowieso wel.

[BlackShadow]

HarmoniousVibe schreef op woensdag 27 juli 2011 @ 11:30:
[...]

Kun je bij die Samsungs CCTL niet aanzetten? Dan is het risico minder groot. Kijk anders ook eens naar Hitachi's. Volgens mij kunnen die dat sowieso wel.

TLER is idd niet het enige probleem met de WD's.
Is CCTL dan permanent aan te zetten, dus ook nog actief na reboot of power loss?

[FireDrunk]

Volgens mij zijn er maar heel weinig disks waarbij je het permanent kan maken, volgens mij zijn de Hitachi's de enige die dat permanent onthouden, anderen moeten dat bij boot te horen krijgen...

[Verwijderd]

Hitachi = ook CCTL hoor, meen ik. En Seagate gebruikt ERC. Beide zijn 'volatile' dus verliezen hun instelling na stroomverlies. Alleen TLER is een permanente setting. Het idee is dat controllers die CCTL/ERC ondersteunen deze bij elke power-up cycle versturen naar de disk, en dus op de door hen gewenste setting krijgen.

[BlackShadow]

Verwijderd schreef op woensdag 27 juli 2011 @ 12:07:
Hitachi = ook CCTL hoor, meen ik. En Seagate gebruikt ERC. Beide zijn 'volatile' dus verliezen hun instelling na stroomverlies. Alleen TLER is een permanente setting. Het idee is dat controllers die CCTL/ERC ondersteunen deze bij elke power-up cycle versturen naar de disk, en dus op de door hen gewenste setting krijgen.

Is er een manier om deze settings te doen bij een Adaptec 5805?
Ik heb al met dergelijke tools geprobeerd, maar geraak niet 'door' de controller.
Ik denk zelfs dat dit enkel lukt met bepaalde Linux drivers...

Als dit echt een issue is bij oa de WD20EARS, hoe komt het dat ik hier in 2 maand nog geen enkele fail heb opgemerkt? Ik heb geen speciale settings ofzo gedaan bij de installatie, ik was me op die moment van geen kwaad bewust. Of heb ik gewoon geluk en is het een kwestie van tijd?

Als ik nu deze array ga uitbreiden met dezelfde disks, dan wordt de kans natuurlijk veel groter dat er een schijf faalt...

[ Voor 6% gewijzigd door BlackShadow op 27-07-2011 12:44 ]

[Verwijderd]

Je krijgt pas problemen als je schijven bad sectors krijgen. In de SMART data zie je die als "Current Pending Sector". Die waardes verdwijnen als de bad sectors worden overschreven, zodat ze kunnen worden omgewisseld voor reserve sectoren. Dan zie je de bad sectors als Reallocated Sector Count in je output. Dat laatste betekent overigens niet automatisch dat je echt onleesbare sectoren hebt gehad; hardeschijven vervangen ook uit voorzorg 'weak sectors' waarbij het langer dan gemiddeld duurt voordat deze leesbaar waren; en dus mogelijk in de toekomst helemaal onleesbaar zouden worden. Om die reden worden dit type sectoren al bij voorbaat omgewisseld; je hebt toch genoeg reserve sectoren.

De problemen beginnen zodra een sector echt bad is, de schijf zal dan blijven proberen deze te lezen als deze wordt opgevraagd. De meeste RAID controllers beschouwen een hardeschijf als kapot als deze niet binnen 10 seconden reageren op een I/O request; dan krijg je dus een 'timeout' en controllers reageren hierop door de schijf af te koppelen en als gefaald te beschouwen. Volkomen absurd natuurlijk, maar dat is de reden dat je voor dergelijke controllers TLER/CCTL/ERC nodig hebt. TLER werkt hierbij altijd omdat het niet van controller support afhankelijk is; je kunt het buiten de controller om 1x instellen en dan blijft het werken. CCTL en ERC moeten echter bij elke boot/power cycle door de controller worden ingeschakeld, en zijn dus afhankelijk van controller support.

Je kunt er dus voor kiezen om gewoon WD EARS met hardware RAID te gebruiken. Maar investeer dan in een hele goede backup, want je moet er rekening mee houden dat je over een jaar of wat met een array zit waar twee of meer schijven uit de array zijn gegooid. Of bijvoorbeeld één en tijdens het rebuilden flikkert een andere schijf eruit; problemen!

[HarmoniousVibe]

Verwijderd schreef op woensdag 27 juli 2011 @ 12:07:
Hitachi = ook CCTL hoor, meen ik. En Seagate gebruikt ERC. Beide zijn 'volatile' dus verliezen hun instelling na stroomverlies. Alleen TLER is een permanente setting. Het idee is dat controllers die CCTL/ERC ondersteunen deze bij elke power-up cycle versturen naar de disk, en dus op de door hen gewenste setting krijgen.

Klopt, je moet het bij Samsungs wel na elke reboot aangeven, wat defacto betekent dat je OS of je raidkaart wel in staat moet kunnen zijn de juiste (ATA) commando's te sturen naar de schijven en dat kan alleen dmv ATA passthrough (OS) of als je raidkaart het ondersteunt via die kaart.

Ik meen ergens gelezen te hebben dat bij Hitachi's deze setting niet volatiel was (als je deze instelt via de Hitachi Feature Tool), maar daarin kan ik me vergissen.

Volgens mij moet CCTL/ERC aanpassen via ATA passthrough gewoon werken op jouw controller, dus als je non-WD-disks hebt, kun je deze setting aanzetten, ook al is het geen dure 'raid ready'-schijf.

sudo smartctl -d sat -l scterc /dev/sdX

Hiermee kun je kijken wat de huidige instelling is. Met

sudo smartctl -d sat -l scterc,70,70 /dev/sdX

kun je de instellingen veranderen. Syntax is als volgt:

scterc[,READTIME,WRITETIME] - [ATA only] [NEW EXPERIMENTAL SMARTCTL FEATURE] prints values and descriptions of the SCT Error Recovery Control settings. These are equivalent to TLER (as used by Western Digital), CCTL (as used by Samsung and Hitachi) and ERC (as used by Seagate). READTIME and WRITETIME arguments (deciseconds) set the specified values. Values of 0 disable the feature, other values less than 65 are probably not supported. For RAID configurations, this is typically set to 70,70 deciseconds.

Let er dus op dat de tijd in decisecondes is! Deze setting werkt NIET met WD's. Je krijgt deze error als je probeert de instelling uit te lezen met het eerste commando uit mijn post:

Warning: device does not support SCT Error Recovery Control command

Note 1: Die Adaptec kan volgens mij via de SAT layer worden benaderd, maar het zou kunnen dat andere kaarten een andere layer nodig hebben. Zie hiervoor: http://sourceforge.net/ap...upported_RAID-Controllers

Note 2: Je hebt smartmontools >=5.40 nodig om deze setting te kunnen lezen of wijzigen.

[ Voor 53% gewijzigd door HarmoniousVibe op 27-07-2011 13:11 ]

[TrailBlazer]

net het raid-test scriptje gebruikt met ext3

| CHUNKS | LEVEL | WRITE | READ |
       4       5     137    137
       8       5     127     97
      16       5     129    104
      32       5     124     99
      64       5     121    125
     128       5     118    148
     256       5     115    185
     512       5     104    184
    1024       5      79    182

Op dit moment heb ik 3 schijven in raid5 zitten. De beste lijkt 256 te zijn. Hoewel ik hem puur als NAS zal gebruiken dus als ik mijn gbit nic vol krijg vind ik het best.

Ook nog een test met XFS gedaan

root@storage:/var/log# more raid-test.log
| CHUNKS | LEVEL | WRITE | READ |
       4       5     277    143
       8       5     235    105
      16       5     239    106
      32       5     241    115
      64       5     246    130
     128       5     234    167
     256       5     211    183
     512       5     198    202
    1024       5      98    178
root@storage:/var/log#

dat scheelt zeker een slok op een borrel zeg. Wel bijzonder dat de hoogste write hoger is dan de hoogste read? Enig ideewaar dat vandaan komt.
Ik ga denk ik maar voor XFS icm een chunksize van 256.


Als er meer schijven bijkomen wat zal dan een beter performance geven een grotere of kleinere chunk size?

[ Voor 30% gewijzigd door TrailBlazer op 27-07-2011 18:46 ]

[BlackShadow]

HarmoniousVibe schreef op woensdag 27 juli 2011 @ 12:50:...

Verwijderd schreef op woensdag 27 juli 2011 @ 12:49:...

Bedankt voor jullie uitleg.

Concludeer ik dan goed dat bij software RAID deze beperkingen makkelijker aan te pakken zijn?

[FireDrunk]

XFS is over het algemeen ook iets sneller, ook met meer disks... Ikzelf heb op mijn ene XFS array 64k en op de andere 128 dacht ik, maakt niet zo heel veel uit... (2 arrays van 8 disks)

[HarmoniousVibe]

BlackShadow schreef op woensdag 27 juli 2011 @ 21:26:
[...]


[...]


Bedankt voor jullie uitleg.

Concludeer ik dan goed dat bij software RAID deze beperkingen makkelijker aan te pakken zijn?

Dan zijn er in ieder geval minder beperkingen die je überhaupt hoeft aan te pakken.

[pieterrr]

Hoe monitoren jullie de status van je RAID array? Bijvoorbeeld of er een schijf is uitgevallen.
Dit omdat het in mijn geval gaat om een headless server/NAS. Deze staat netjes in een hoek weggewerkt dus ledjes oid is ook niet super handig.
Er draait btw Ubuntu server op.

[Nielson]

pieterrr schreef op donderdag 28 juli 2011 @ 00:31:
Hoe monitoren jullie de status van je RAID array? Bijvoorbeeld of er een schijf is uitgevallen.

mdadm heeft een ingebouwde monitor optie.

[Sleepie]

Nielson schreef op donderdag 28 juli 2011 @ 00:36:
[...]
mdadm heeft een ingebouwde monitor optie.

Jup, en die werkt prima

Hier het berichtje wat ik gemaild kreeg toen ik een disk failde in mijn array (die disk moest vervangen worden)

This is an automatically generated mail message from mdadm running on WEGA

A DegradedArray event had been detected on md device /dev/md/0.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdk[9] sdj[8] sdi[7] sdh[6] sdf[4] sde[3] sdd[2] sdc[1] sdb[0]
      11721099264 blocks super 1.2 level 6, 64k chunk, algorithm 2 [10/9] [UUUUU_UUUU]
      
unused devices: <none

[Sleepie]

Ok, dat was de goden verzoeken denk ik.

Ik krijg nu net een mailtje binnen dat /dev/sde is gefailed in mijn array (en deze keer niet omdat ik zelf een mdadm --fail commando gaf).
Nog een disk met problemen?

De smartctl output:

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   051    Pre-fail  Always       -       18
  3 Spin_Up_Time            0x0007   063   063   011    Pre-fail  Always       -       11710
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       39
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0025   100   100   015    Pre-fail  Offline      -       10818
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       926
 10 Spin_Retry_Count        0x0033   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   000    Old_age   Always       -       1
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       39
 13 Read_Soft_Error_Rate    0x000e   100   100   000    Old_age   Always       -       18
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   000    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       18
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   070   068   000    Old_age   Always       -       30 (Lifetime Min/Max 27/31)
194 Temperature_Celsius     0x0022   070   067   000    Old_age   Always       -       30 (Lifetime Min/Max 27/35)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       1569643398
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age   Always       -       0
201 Soft_Read_Error_Rate    0x000a   099   099   000    Old_age   Always       -       22

Deze disk is dus uit mijn array gegooid.
Kan ik deze disk nog vertrouwen?

[Verwijderd]

Je hebt 2 pending sectors; dat is je probleem. Dat zijn actieve bad sectors. Zie hier voor een uitleg:
Verwijderd in "RMA aanvragen voor HD, zin of geen zin?"

Je kunt die sectoren gewoon overschrijven. Makkelijkste is een zero-write op de disk. Dan nogmaals SMART checken en je Current Pending Sector hoort 0 te zijn. Dan weer toevoegen aan je array die dan een rebuild start.

[Sleepie]

Verwijderd schreef op donderdag 28 juli 2011 @ 17:04:
Je hebt 2 pending sectors; dat is je probleem. Dat zijn actieve bad sectors. Zie hier voor een uitleg:
Verwijderd in "RMA aanvragen voor HD, zin of geen zin?"

Je kunt die sectoren gewoon overschrijven. Makkelijkste is een zero-write op de disk. Dan nogmaals SMART checken en je Current Pending Sector hoort 0 te zijn. Dan weer toevoegen aan je array die dan een rebuild start.

En gezien het aantal is de disk dan nog wel betrouwbaar?

Het gekke is, ik heb bijna 2 jaar OpenFiler met 4 disks in mdadm raid5 gedraaid.
In die twee jaar heb ik geen enkel probleem met bad sectors ofzo gehad, dit is nu al de tweede disk waarop ik errors krijg.
'Toevallig' zijn dat 2 van de 6 nieuwe disks die ik heb bijgekocht (die 4 oude disks maken intussen ook deel uit van mijn raid6 array).

Ik zou bijna gaan denken dat ik een batch met slechte disks te pakken heb?

[Nielson]

Hier wordt een alternatieve manier uitgelegd: Forcing a hard disk to reallocate bad sectors

[Verwijderd]

Een paar pending sectors is gewoon normaal hoor. Je hoort er nu meer over omdat de datadichtheid toeneemt. Dat betekent dat je meer opslag hebt, terwijl de uBER spec gelijk blijft. Die specificatie zegt dat je per grofweg 90 terabyte I/O een bad sector krijgt. Toen de schijven nog 1 gigabyte waren was dat vrij zeldzaam, maar nu de schijven 2 terabyte zijn krijg je daar dus relatief gezien veel meer last van.

Op 50% van mijn oudere schijven zijn er bad sectors. Het leuke is dat ik ZFS gebruik en daar dus helemaal geen last van heb. ZFS repareert deze automatisch door er naar te schrijven, dan wisselt de HDD ze gelijk om. Je hebt met ZFS dus nooit last van uitvallende schijven door bad sectors; ZFS is vrijwel imuun voor bad sectors. Voorwaarde is wel dat je een 100% software controller (non-RAID) gebruikt. RAID controllers disconnecten schijven die geen TLER/CCTL/ERC geactiveerd hebben zodra die een bad sector tegenkomen en langer dan 10 seconden aan recovery doen.

In jouw geval gewoon even zero-writen en weer toevoegen. Het kan wel een reden zijn om voor RAID6 te kiezen: dan bescherm je je tegen één disk die helemaal gecrashed is en één disk die een bad sector krijgt tijdens het rebuilden. Wil je echte zekerheid, kies dan voor ZFS.

[Sleepie]

Verwijderd schreef op donderdag 28 juli 2011 @ 18:20:
Een paar pending sectors is gewoon normaal hoor. Je hoort er nu meer over omdat de datadichtheid toeneemt. Dat betekent dat je meer opslag hebt, terwijl de uBER spec gelijk blijft. Die specificatie zegt dat je per grofweg 90 terabyte I/O een bad sector krijgt. Toen de schijven nog 1 gigabyte waren was dat vrij zeldzaam, maar nu de schijven 2 terabyte zijn krijg je daar dus relatief gezien veel meer last van.

Op 50% van mijn oudere schijven zijn er bad sectors. Het leuke is dat ik ZFS gebruik en daar dus helemaal geen last van heb. ZFS repareert deze automatisch door er naar te schrijven, dan wisselt de HDD ze gelijk om. Je hebt met ZFS dus nooit last van uitvallende schijven door bad sectors; ZFS is vrijwel imuun voor bad sectors. Voorwaarde is wel dat je een 100% software controller (non-RAID) gebruikt. RAID controllers disconnecten schijven die geen TLER/CCTL/ERC geactiveerd hebben zodra die een bad sector tegenkomen en langer dan 10 seconden aan recovery doen.

In jouw geval gewoon even zero-writen en weer toevoegen. Het kan wel een reden zijn om voor RAID6 te kiezen: dan bescherm je je tegen één disk die helemaal gecrashed is en één disk die een bad sector krijgt tijdens het rebuilden. Wil je echte zekerheid, kies dan voor ZFS.

Ik ben al een zero-write aan het uitvoeren en dan gaat de disk weer terug in de array. Dat is trouwens een RAID6 array, toen ik van 4 naar 10 disks ging ben ik ook meteen overgestapt van RAID5 naar RAID6.
Het is alleen opvallend dat ik er in 2 jaar geen last van heb gehad en nu opeens al 2 keer in 2 weken

ZFS staat zeker in de planning hier. Het probleem was dat ik in totaal 10 disks had hier, waarvan er 4 een bestaande RAID5 array vormden. En de data die daarop stond kon ik nergens anders kwijt zodat ik een 10 disk RAIDZ2 kon maken.

Het (toekomstige) plan is nu het volgende:
Ik ga nog 10 disks bijkopen en daar maak ik dan een RAIDZ2-pool van. Dan de data overzetten van de mdadm RAID6 pool naar de ZFS pool en vervolgens die 10 disks als een tweede RAIDZ2 pool toevoegen.
Ik heb me nog niet 100% ingelezen in ZFS (volg het topic uiteraard wel), maar volgens mij moet bovenstaande kunnen

[Verwijderd]

10-disk RAID-Z2 is een mooie config ja, zeker als je er twee gebruikt en dus de ene pool ook (gedeeltelijk) backup kan zijn. Als je 4K sector schijven hebt (Samsung F4EG, WD EARS) dan is een 10-disk RAID-Z2 ook een optimale configuratie; dus dat kan eigenlijk niet fout gaan. Met RAID-Z2 zou je data extreem veilig moeten zijn tegen hardwaredefecten; alleen userfouten, electrische problemen en rampen zouden dan nog voor dataverlies kunnen zorgen.

[Sleepie]

Verwijderd schreef op donderdag 28 juli 2011 @ 18:52:
10-disk RAID-Z2 is een mooie config ja, zeker als je er twee gebruikt en dus de ene pool ook (gedeeltelijk) backup kan zijn. Als je 4K sector schijven hebt (Samsung F4EG, WD EARS) dan is een 10-disk RAID-Z2 ook een optimale configuratie; dus dat kan eigenlijk niet fout gaan. Met RAID-Z2 zou je data extreem veilig moeten zijn tegen hardwaredefecten; alleen userfouten, electrische problemen en rampen zouden dan nog voor dataverlies kunnen zorgen.

De huidige schijven zijn 1.5TB Samsung F2 HD154UI schijven.
Als ik nieuwe koop (al zal dat nog even duren, dus wie weet wat er dan op de markt is) zullen het inderdaad de 2TB F4EG's worden. Vandaar dat ik het geheel ook 'per-10-disks' bekijk.

Electrische problemen zouden tegen die tijd opgevangen moeten worden door een UPS

* Sleepie heeft plannen genoeg, ik zoek nog een bank die het allemaal wil sponsoren

[Mafketel]

Verwijderd schreef op maandag 25 juli 2011 @ 03:11:
Voorheen hadden alle Athlon en Phenom CPUs ECC ondersteuning, als ik het goed heb. Alleen de budget reeks Duron/Sempron niet. Correct me if i'm wrong!

sempron 140 heeft volgens mij wel ecc ondersteuning, en duron was nog voor de ingebouwde geheugencontroller volgens mij.

[thestiffmeister]

Sleepie schreef op donderdag 28 juli 2011 @ 19:10:
[...]

De huidige schijven zijn 1.5TB Samsung F2 HD154UI schijven.
Als ik nieuwe koop (al zal dat nog even duren, dus wie weet wat er dan op de markt is) zullen het inderdaad de 2TB F4EG's worden. Vandaar dat ik het geheel ook 'per-10-disks' bekijk.

Electrische problemen zouden tegen die tijd opgevangen moeten worden door een UPS

* Sleepie heeft plannen genoeg, ik zoek nog een bank die het allemaal wil sponsoren

Ik ben me nu aan het orienteren voor een nieuwe DIY Raid oplossing.
Zit dus nu te twijfelen over het besturingssysteem en de te gebruiken RAID-config.
Gebruiken jullie hiervoor Solaris of FreeNas o.i.d?

Ik twijfel tussen een Debian, FreeNas en een Solaris install. Zit te dubben over Solaris maar heeft een meer beperkte ondersteuning voor hardware.

Die veiligheidsrisicos die baren me nogal zorgen voor al mijn data. Ik weet dat Raid niet kan dienen als backup en het meeste heb ik nog op ouderwetse DAT (80GB) tapes staan maar toch zou ik meer zekerheid over mijn normale Raid-pool willen hebben (met HDs).

Ik zit daarbij te dubben over MDADM Raid 6 en dus ZFS.

Is ZFS b.t.w. ook on-the-fly uit te breiden met meer schijven? Of is dat alleen mogelijk met MDADM?
Daarbij de vraag over de electriciteitsproblemen.... Indien de power eruit klapt zonder goed te unmounten..... is dit dan een serieus probleem of valt er dan nog het een en ander te herstellen?
(Die bank heb ik nl. nog niet gevonden en de eerste intentie is te starten met 4 * 3TB).

Daarbij de vraag over dat TLER. Met software raid heb je hier zowiezo geen last van toch? (gezien de post "to Forcing a hard disk to reallocate bad sectors").

[ Voor 5% gewijzigd door thestiffmeister op 28-07-2011 23:04 ]

[Sleepie]

ZFS kun je niet zonder meer uitbreiden met meer schijven
Als je een RAIDZ pool van 5 disks hebt...kun je uitbreiden met nog zo'n pool van 5 disks (en dus niet met 1 disk).
Een mdadm raid kun je gewoon telkens met 1 disk uitbreiden, al gaat het rebuilden op een gegeven moment wel veel tijd kosten (ik deed er met 10 x 1.5 TB nu zo'n 6-7 uur over).

Als je 4kB sector disks hebt (de meeste 2 TB disks dus) kun je voor RAIDZ2 (de ZFS raid6 equivalent) beter 5 disks nemen, zoek maar wat terug in dit topic over het hoe en waarom).

Dat was voor mij voor nu de reden om een mdadm raid6 set te maken, ik draai die onder Ubuntu 11.04 Server.

Als je echt veilig wilt, is ZFS de betere keuze (bescherming tegen bitrot, die mdadm niet heeft), maar uiteraard de echt belangrijke dingen nog steeds backupen!

[HarmoniousVibe]

Nou je kunt hem uitbreiden met nog een pool. In het geval van raidz1 zijn dat minimaal 3 schijven en bij raidz2 4. Ze hoeven dus niet allemaal even groot te zijn afaik.

MDADM kan dat inderdaad wel. Rebuilden kost inderdaad flink wat tijd, maar het is niet zo dat je array degraded is ofzo terwijl je aan het rebuilden bent. Maar goed, mdadm heeft zo zijn eigen nadelen.

[thestiffmeister]

Sleepie schreef op donderdag 28 juli 2011 @ 23:08:
ZFS kun je niet zonder meer uitbreiden met meer schijven
Als je een RAIDZ pool van 5 disks hebt...kun je uitbreiden met nog zo'n pool van 5 disks (en dus niet met 1 disk).
Een mdadm raid kun je gewoon telkens met 1 disk uitbreiden, al gaat het rebuilden op een gegeven moment wel veel tijd kosten (ik deed er met 10 x 1.5 TB nu zo'n 6-7 uur over).

Als je 4kB sector disks hebt (de meeste 2 TB disks dus) kun je voor RAIDZ2 (de ZFS raid6 equivalent) beter 5 disks nemen, zoek maar wat terug in dit topic over het hoe en waarom).

Dat was voor mij voor nu de reden om een mdadm raid6 set te maken, ik draai die onder Ubuntu 11.04 Server.

Als je echt veilig wilt, is ZFS de betere keuze (bescherming tegen bitrot, die mdadm niet heeft), maar uiteraard de echt belangrijke dingen nog steeds backupen!

Voor ZFS ga je dan automatisch voor FreeNAS of Solaris? Solaris wordt voor mij evt. nog een probleem met de te nieuwe hardware. Die nieuwste FreeNAS zal wel gaan lukken.
Indien je dan gaat kiezen voor ZFS is de onboard SATA controller toch toereikend mag ik aannemen? Of heb je hiervoor een andere HBA nodig (met mogelijke driverissues van dien).

Bij een electriciteitsfailure (dat gebeurt hier nog wel eens), kan die ZFS rebuilden of is alle data dan helaas verloren (bij het niet correct unmounten)? Ben op ZFS gebied een noob (moet idd dit topic dan beter bestuderen).

[Sleepie]

thestiffmeister schreef op donderdag 28 juli 2011 @ 23:17:
[...]


Voor ZFS ga je dan automatisch voor FreeNAS of Solaris? Solaris wordt voor mij evt. nog een probleem met de te nieuwe hardware. Die nieuwste FreeNAS zal wel gaan lukken.
Indien je dan gaat kiezen voor ZFS is de onboard SATA controller toch toereikend mag ik aannemen? Of heb je hiervoor een andere HBA nodig (met mogelijke driverissues van dien).

Bij een electriciteitsfailure (dat gebeurt hier nog wel eens), kan die ZFS rebuilden of is alle data dan helaas verloren (bij het niet correct unmounten)? Ben op ZFS gebied een noob (moet idd dit topic dan beter bestuderen).

Ik ben zelf ook niet de grootste ZFS expert hier, aangezien ik (nog) mdadm gebruik.

Maar ik denk dat je eens in dit topic moet gaan lezen:
Het grote ZFS topic

[thestiffmeister]

Sleepie schreef op donderdag 28 juli 2011 @ 23:20:
[...]

Ik ben zelf ook niet de grootste ZFS expert hier, aangezien ik (nog) mdadm gebruik.

Maar ik denk dat je eens in dit topic moet gaan lezen:
Het grote ZFS topic

THX! Dat is idd. handig

[DJ-Visto]

Iemand nog een idee hoe ik deze array een stukje sneller kan krijgen?

Specs:

X2 7850
4GB mem
2x Hitachi 1TB
1x Samsung F3 1TB

MDADM rRAID5 Debian Lenny. XFS geformatteerd, word gebruikt als VM storage/booten (Hier op draaien de vms ook dus) Via NFS naar ESXi nu nog over 1Gbps lijntje, word binnenkort wat meer denk ik 2Gbps oid.

Test op de machine zelf:

code:

vincent@Shiffle:~$ sudo dd if=/dev/zero of=/opslag/raid0/test.bin bs=1M count=10000
   10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 196.517 s, 53.4 MB/s

code:

vincent@Shiffle:~$ sudo dd if=/opslag/raid0/test.bin of=/dev/null
20480000+0 records in
20480000+0 records out
10485760000 bytes (10 GB) copied, 97.5883 s, 107 MB/s

MDADM detail:

code:

vincent@Shiffle:~$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sun Jul 10 00:35:16 2011
     Raid Level : raid5
     Array Size : 1953524992 (1863.03 GiB 2000.41 GB)
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Thu Jul 28 23:10:42 2011
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : e8ca7701:719f90ee:9cfd4c97:e1e53fb8
         Events : 0.20

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd

Test op een vm: (gecanceld maar je ziet hoe traag het is)

code:

vincent@Webserver:~$ sudo dd if=/dev/zero of=/home/vincent/test.bin bs=1M count=10000
^C7143+0 records in
7143+0 records out
7489978368 bytes (7.5 GB) copied, 1118.55 s, 6.7 MB/s

code:

vincent@Webserver:~$ sudo dd if=/home/vincent/test.bin of=/dev/null
14628864+0 records in
14628864+0 records out
7489978368 bytes (7.5 GB) copied, 177.297 s, 42.2 MB/s

Echt jammer dit Ach men moet ook wat leren, en heb nu een 12TB array om op te backuppen en het te kunnen wijzingen, maar zoveel werk, eerst nog lekker 2weken echt vakantie in het buitenland houden (ja en daarintegen als een echte nerd toch lekker even tweaken)

Wat is jullie advies? Perfomance is voornamelijk de wil, upgrade naar squeeze? Of hem ander inrichten?

Oh en nog even een perfomance testje op de RAID5 8*2TB Op een HP Smart Array P400 me 256MB cache.
Die staat op 25% read 75% write

code:

vincent@Shiffle:~$ sudo dd if=/dev/zero of=/opslag/raid5/test.bin bs=1M count=10000
[sudo] password for vincent:
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 45.2599 s, 232 MB/s

code:

vincent@Shiffle:~$ sudo dd if=/opslag/raid5/test.bin of=/dev/null
20480000+0 records in
20480000+0 records out
10485760000 bytes (10 GB) copied, 76.5322 s, 137 MB/s

[ Voor 9% gewijzigd door DJ-Visto op 28-07-2011 23:43 ]

[iMars]

DJ-Visto schreef op donderdag 28 juli 2011 @ 23:37:
Iemand nog een idee hoe ik deze array een stukje sneller kan krijgen?

Specs:

X2 7850
4GB mem
2x Hitachi 1TB
1x Samsung F3 1TB

MDADM rRAID5 Debian Lenny. XFS geformatteerd, word gebruikt als VM storage/booten (Hier op draaien de vms ook dus) Via NFS naar ESXi nu nog over 1Gbps lijntje, word binnenkort wat meer denk ik 2Gbps oid.

Test op de machine zelf:

code:

vincent@Shiffle:~$ sudo dd if=/dev/zero of=/opslag/raid0/test.bin bs=1M count=10000
   10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 196.517 s, 53.4 MB/s

code:

vincent@Shiffle:~$ sudo dd if=/opslag/raid0/test.bin of=/dev/null
20480000+0 records in
20480000+0 records out
10485760000 bytes (10 GB) copied, 97.5883 s, 107 MB/s

MDADM detail:

code:

vincent@Shiffle:~$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sun Jul 10 00:35:16 2011
     Raid Level : raid5
     Array Size : 1953524992 (1863.03 GiB 2000.41 GB)
  Used Dev Size : 976762496 (931.51 GiB 1000.20 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Thu Jul 28 23:10:42 2011
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : e8ca7701:719f90ee:9cfd4c97:e1e53fb8
         Events : 0.20

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd

Test op een vm: (gecanceld maar je ziet hoe traag het is)

code:

vincent@Webserver:~$ sudo dd if=/dev/zero of=/home/vincent/test.bin bs=1M count=10000
^C7143+0 records in
7143+0 records out
7489978368 bytes (7.5 GB) copied, 1118.55 s, 6.7 MB/s

code:

vincent@Webserver:~$ sudo dd if=/home/vincent/test.bin of=/dev/null
14628864+0 records in
14628864+0 records out
7489978368 bytes (7.5 GB) copied, 177.297 s, 42.2 MB/s

Echt jammer dit Ach men moet ook wat leren, en heb nu een 12TB array om op te backuppen en het te kunnen wijzingen, maar zoveel werk, eerst nog lekker 2weken echt vakantie in het buitenland houden (ja en daarintegen als een echte nerd toch lekker even tweaken)

Wat is jullie advies? Perfomance is voornamelijk de wil, upgrade naar squeeze? Of hem ander inrichten?

Wat heb je allemaal geprobeerd?

Heb je ook mijn post gezien? iMars in "Het grote DIY RAID NAS topic deel 3"
Daarin wordt naar een script verwezen die het een en ander optimaliseert, ook staat er een testscript die kijkt welke chunksize het 'beste' is voor je array...

[DJ-Visto]

Zal ik proberen als ik thuis ben, maar ik werk er nu op, en word het lastig omdat nu te gaan umounten enzo, ik dacht dat iemand het misschien zo kon ophoesten

[iMars]

DJ-Visto schreef op donderdag 28 juli 2011 @ 23:51:
Zal ik proberen als ik thuis ben, maar ik werk er nu op, en word het lastig omdat nu te gaan umounten enzo, ik dacht dat iemand het misschien zo kon ophoesten

Was het maar zo simpel

[DJ-Visto]

iMars schreef op vrijdag 29 juli 2011 @ 00:14:
[...]

Was het maar zo simpel

Dan zou het leven easy zijn

[Sleepie]

Verwijderd schreef op donderdag 28 juli 2011 @ 17:04:
Je hebt 2 pending sectors; dat is je probleem. Dat zijn actieve bad sectors. Zie hier voor een uitleg:
Verwijderd in "RMA aanvragen voor HD, zin of geen zin?"

Je kunt die sectoren gewoon overschrijven. Makkelijkste is een zero-write op de disk. Dan nogmaals SMART checken en je Current Pending Sector hoort 0 te zijn. Dan weer toevoegen aan je array die dan een rebuild start.

Intussen de zero-write en rebuild uitgevoerd. Na de zero-write had ik inderdaad een paar reallocated sectors.
Echter, tijdens de rebuild zijn er daar weer een aantal bijgekomen

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   051    Pre-fail  Always       -       57
  3 Spin_Up_Time            0x0007   063   063   011    Pre-fail  Always       -       11710
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       39
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       20
  7 Seek_Error_Rate         0x000f   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0025   100   100   015    Pre-fail  Offline      -       10818
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       944
 10 Spin_Retry_Count        0x0033   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   000    Old_age   Always       -       1
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       39
 13 Read_Soft_Error_Rate    0x000e   100   100   000    Old_age   Always       -       57
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   000    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       57
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   068   067   000    Old_age   Always       -       32 (Lifetime Min/Max 27/33)
194 Temperature_Celsius     0x0022   068   067   000    Old_age   Always       -       32 (Lifetime Min/Max 27/35)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       1639410872
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       20
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age   Always       -       0
201 Soft_Read_Error_Rate    0x000a   099   099   000    Old_age   Always       -       44

In totaal dus 20 reallocated sectors intussen.
Bovendien is de laatste waarde "Soft_Read_Error_Rate" ook omhoog gegaan.

Ben ik nou gek als ik deze disk niet echt vertrouw (en dan niet vanwege de paar bad sectors waar het mee begon, maar meer omdat er weer een aantal bij zijn gekomen tijdens de rebuild) ?

[Jormungandr]

Intussen zijn alledrie mijn samsungs door badblock gehaald en er zijn gee errors gevonden.
Tijd dus om langzaam aan alles te migreren van de Synology naar de nas.

Temperatuurmetingen tonen echter wel dat de disks tegen 40 graden aan lopen, wat niet verwonderlijk is aangezien ze in een Aopen H600B behuizing zitten die duidelijk nog niet van correcte koeling gehoord heeft. Dan maar eens checken voor een nieuwe case.

Ik dacht trouwens dat er hier iets gepost was ivm SMART over LSI2008 karten? phpsysinfo toont geen smart informatie atm maar daar moet wel een oplossing voor zijn.

[Verwijderd]

Sleepie schreef op vrijdag 29 juli 2011 @ 10:35:
[...]

Intussen de zero-write en rebuild uitgevoerd. Na de zero-write had ik inderdaad een paar reallocated sectors.
Echter, tijdens de rebuild zijn er daar weer een aantal bijgekomen

In totaal dus 20 reallocated sectors intussen.
Bovendien is de laatste waarde "Soft_Read_Error_Rate" ook omhoog gegaan.

Ben ik nou gek als ik deze disk niet echt vertrouw (en dan niet vanwege de paar bad sectors waar het mee begon, maar meer omdat er weer een aantal bij zijn gekomen tijdens de rebuild) ?

In totaal 57 bad sectors. Merk op dat niet alle bad sectors ook fysiek slecht zijn; je hebt ook bad sectors waarvan de electric charge onvoldoende was om door ECC gecorrigeerd te worden, maar fysiek nog steeds in orde is. Dat laatste kan komen door sectoren die lang geleden zijn beschreven maar sindsdien niet meer zijn overschreven; ze verliezen dan hun electric charge tot op het punt dat de ECC te bit fouten niet meer kan corrigeren. Dat is in jouw geval dus 57 - 20 = 37 keer gebeurd.

Pending Sectoren zijn in principe wel vervelend. Als je disk lange tijd onbeschreven is kun je alle sectoren 'verversen' zonder dataverlies met het volgende commando:
dd if=/dev/sdR of=/dev/sdR bs=1M
(vervang sdR door de device naam; zowel if= als of= moeten dezelfde device zijn)

Bovenstaand commando leest data van de schijf en schrijft exact dezelfde data; dus alle sectoren worden gelezen en overschreven met exact dezelfde data. Dat zorgt ervoor dat de electric charge wordt ververst. Je kunt de bs=1M ook naar bs=100M doen zodat het sneller gaat (niet continu hoeven wisselen tussen read en write). De blocksize moet echter wel in je RAM passen dus maak deze niet te hoog. Ook mag je schijf absoluut niet gebruikt worden tijdens dit commando! Gooi hem dus uit de array voordat je dit commando draait.

Maar je kunt er ook voor kiezen om ter garantie aan te bieden; met als argument dat er blocks bij blijven komen en dat dat gewoon vervelend is. De soft read errors hoef je je geen zorgen om te maken; maar de bad/weak sectors zijn wel meer dan gebruikelijk. Als het nou bij 2 pending sectors bleef is dat vrij normaal, maar 57 is alweer een redelijk hoog aantal. Desondanks kan de schijf prima nog 10 jaar functioneren; dat je bad sectors hebt wil niet zeggen dat dat een reden is om te denken dat de schijf binnenkort er helemaal mee op kan houden. Maar dit probleem is opzich al irritant genoeg om aan vervanging te denken.

[Verwijderd]

thestiffmeister schreef op donderdag 28 juli 2011 @ 23:17:
Indien je dan gaat kiezen voor ZFS is de onboard SATA controller toch toereikend mag ik aannemen? Of heb je hiervoor een andere HBA nodig (met mogelijke driverissues van dien).

Onboard SATA = het allerbeste wat er bestaat. HBA is de 2e keus, je kunt prima onboard SATA en HBA combineren; ook in dezelfde pool.

Bij een electriciteitsfailure (dat gebeurt hier nog wel eens), kan die ZFS rebuilden of is alle data dan helaas verloren (bij het niet correct unmounten)? Ben op ZFS gebied een noob (moet idd dit topic dan beter bestuderen).

ZFS is extreem veilig voor power failures; je zult hier nooit omkijken naar hebben. Enige uitzondering is als je RAID controllers met write-back gebruikt; je moet ZFS wel volledige controle over de fysieke schijven geven, zonder dat er dingen tussen zitten die de veiligheidsfeatures van ZFS verkrachten. ZFS repareert automatisch alle schade; je hoeft geen volledige rebuild te draaien. Sowieso kent ZFS alleen een 'scrub' waarbij alleen data wordt gerebuild. Heb je dus 10% data op je pool staan dan wordt maximaal die 10% gecontroleerd en niet alle bits en bytes op alle schijven, zoals met conventionele RAID arrays gebeurt.

Voor meer vragen verwijs ik je naar Het grote ZFS topic.

[FireDrunk]

Zeg CiPHER, wat draai je nu zelf eigenlijk? (zowel hardware als software )

[ Voor 25% gewijzigd door FireDrunk op 29-07-2011 11:32 ]

[Sleepie]

Verwijderd schreef op vrijdag 29 juli 2011 @ 11:27:
[...]

In totaal 57 bad sectors. Merk op dat niet alle bad sectors ook fysiek slecht zijn; je hebt ook bad sectors waarvan de electric charge onvoldoende was om door ECC gecorrigeerd te worden, maar fysiek nog steeds in orde is. Dat laatste kan komen door sectoren die lang geleden zijn beschreven maar sindsdien niet meer zijn overschreven; ze verliezen dan hun electric charge tot op het punt dat de ECC te bit fouten niet meer kan corrigeren. Dat is in jouw geval dus 57 - 20 = 37 keer gebeurd.

Nou, het is allemaal nog erger geworden.

De raid rebuild was intussen klaar, dus ik startte een download op (die naar de array schrijft) en binnen 5 minuten klapt die /dev/sde disk er weer uit.
Deze keer nam hij echter ook heel mijn Linux VM mee, die hing compleet

Current_Pending_Sectors staat nu weer op 13

Die disk gaat dus gewoon retour .... of kan dit probleem nog een andere oorzaak dan een slechte disk hebben?

Overigens is mijn mdadm raid ook niet opgekomen na de reboot, alle drives staan op spare????

root@WEGA:/home/hans# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : inactive sdk[9](S) sdj[8](S) sdi[7](S) sdh[6](S) sdg[10](S) sdf[4](S) sde[11](S) sdd[2](S) sdc[1](S) sdb[0](S)
      14651375600 blocks super 1.2

unused devices: <none>

Hoe los ik dat op?

[FireDrunk]

mdadm --assemble /dev/md0 --force

Uiteraard op eigen risico...

[Sleepie]

FireDrunk schreef op vrijdag 29 juli 2011 @ 12:37:
mdadm --assemble /dev/md0 --force

Uiteraard op eigen risico...

Die stap was ik al voorbij, maar ook dat heeft niet geholpen

Er lijkt een inconsistency te zijn tussen de (probleemdisk) /dev/sde en de overige disks.

Maar ook als ik /dev/sde uit het systeem verwijder, wil de array niet (degraded) starten

mdadm --assemble /dev/md0 /dev/sd[bcdefghijk] geeft mij een melding waar ik echt niet vrolijk van word:
no superblock found

Als ik de array stop, vervolgens /dev/sde verwijder (physiek, hotswap) en weer terug plaats...dan heb ik opeens een array met alleen /dev/sde erin
Vandaar mijn idee dat er ergens een inconsistency is.

[ Voor 15% gewijzigd door Sleepie op 29-07-2011 12:46 ]

[FireDrunk]

Dat heb ik ook wel eens gehad, weet niet meer precies waar dat aan lag...
Je moet sowieso voordat je je array weer wil assemblen, de array helemaal stoppen...

mdadm --stop /dev/md0
mdadm --assemble /dev/md0 --run --force was het geloof ik...

Ik kreeg toen een melding in de trant van "Marking device: /dev/sd* as not faulty" of "Erasing fault status on device:"

[Sleepie]

Het is al te laat, ergens is iets fout gegaan en mijn data is gone ......

* Sleepie zijn vertrouwen in mdadm heeft een flinke deuk opgelopen

[FireDrunk]

Uhm, ik zou niet te snel oordelen... Vaak is er een goede reden dat MDADM je array niet wil assemblen...
Zijn je disks ook allemaal opgespint? Want MDADM is niet happig op een array bouwen op disks die idle zijn...

[Sleepie]

Disks zijn opgespint, maar ik heb zoveel zitten klooien dat het filesystem nu corrupt is.
Gelukkig is de meeste data wel vervangbaar, maar het blijft wel balen natuurlijk

Ik ga die rotte disk in ieder geval uit het systeem halen nu, dan mijn raid maar even opnieuw opbouwen met 9 disks (en weer een disk RMA sturen ).
Die tiende disk add ik dan later wel weer ... of misschien stap ik gewoon meteen maar over naar ZFS nu.

Waarbij ik me nu afvraag:
Een paar bad sectors is op zich niet erg, ZFS kan dat (beter dan mdadm) ook on the fly repareren.
Zou ik het toch nog even proberen met die disk met ZFS?
Ik neem aan dat je in een ZFS-pool toch ook wel disks kunt vervangen?
(Sorry voor de vraag, ik ga meteen inlezen in ZFS nu).

* Sleepie vraagt zich af of hij nu de twijfelachtige eer heeft om de eerste in dit topic te zijn die zo'n 4TB aan data is verloren?

[ Voor 34% gewijzigd door Sleepie op 29-07-2011 13:19 ]

[CurlyMo]

Sleepie schreef op vrijdag 29 juli 2011 @ 13:11:
Een paar bad sectors is op zich niet erg, ZFS kan dat (beter dan mdadm) ook on the fly repareren.
Zou ik het toch nog even proberen met die disk met ZFS?
Ik neem aan dat je in een ZFS-pool toch ook wel disks kunt vervangen?

Ik zou gewoon goed opnieuw beginnen en dus de disk laten vervangen.
Schijven vervangen kan natuurlijk afhankelijk van je RAID level. Maar zoals je ook vast wel weet blijven er ook risico's kleven aan het resilveren van grote pools. Ik zou op dit moment 3 pools maken van RAIDZ met 3 schijven per pool of 2 pools maken van RAIDZ2 met 4 á 5 schijven. Wanneer je kiest voor 4 schijven zou je van de overige 2 schijven een backup mirror kunnen maken. Wanneer er een schijf corrupt is zorg je er tenminste voor dat je met aparte 'kleine' pools nooit mega hoeveelheden data hoeft te resilveren.

[ Voor 18% gewijzigd door CurlyMo op 29-07-2011 13:31 ]

[Sleepie]

CurlyMo schreef op vrijdag 29 juli 2011 @ 13:28:
[...]


Ik zou gewoon goed opnieuw beginnen en dus de disk laten vervangen.
Schijven vervangen kan natuurlijk afhankelijk van je RAID level. Maar zoals je ook vast wel weet blijven er ook risico's kleven aan het resilveren van grote pools. Ik zou op dit moment 3 pools maken van RAIDZ met 3 schijven per pool of 2 pools maken van RAIDZ2 met 4 á 5 schijven. Wanneer je kiest voor 4 schijven zou je van de overige 2 schijven een backup mirror kunnen maken. Wanneer er een schijf corrupt is zorg je er tenminste voor dat je met aparte 'kleine' pools nooit mega hoeveelheden data hoeft te resilveren.

Ben ik met je eens, maar toch is het niet helemaal de weg di ik wil bewandelen

Hoewel ik nu 1.5TB 512kB sector disks heb en ik dus best een RAIDZ2 pool van 9 disks ofzo zou kunnen maken, zal ik in de toekomst ongetwijfeld nog wel overstappen op grotere (en dus 4096kB sector) disks.
Daarom wil ik juist een RAIDZ2 pool van 10 disks maken, dat is optimaal voor die disks.

Vandaar dus ook de vraag of ik die disk met bad sectors (al is het tijdelijk) nog kan inzetten en later vervangen. In dat geval zou ik dan nu een 10disk RAIDZ2 pool kunnen maken, nog even aankijken of het aantal bad sectors nog groeit en afhankelijk daarvan die disk wel of niet vervangen.

Maar als redelijke ZFS n00b weet ik niet eens of je onder ZFS uberhaupt een disk kunt vervangen (ik mag toch aannemen van wel).

[CurlyMo]

Sleepie schreef op vrijdag 29 juli 2011 @ 13:35:
[...]
Vandaar dus ook de vraag of ik die disk met bad sectors (al is het tijdelijk) nog kan inzetten en later vervangen. In dat geval zou ik dan nu een 10disk RAIDZ2 pool kunnen maken, nog even aankijken of het aantal bad sectors nog groeit en afhankelijk daarvan die disk wel of niet vervangen.

Maar als redelijke ZFS n00b weet ik niet eens of je onder ZFS uberhaupt een disk kunt vervangen (ik mag toch aannemen van wel).

Zoals ik eerder aangaf kan dit wel maar je blijft het risico houden dat je tijdens zo'n grote resilvering een tweede disk sloopt. Vandaar kleine zpool groepen...

[Sleepie]

CurlyMo schreef op vrijdag 29 juli 2011 @ 13:39:
[...]
Zoals ik eerder aangaf kan dit wel maar je blijft het risico houden dat je tijdens zo'n grote resilvering een tweede disk sloopt. Vandaar kleine zpool groepen...

In een RAIDZ2 pool mogen er toch 2 disks uitvallen voor je definitief data kwijt bent?
Ondanks mijn ervaring van eerder vandaag, hou ik er toch wel vertrouwen in dat die kans niet echt al te groot is.
Bovendien....'kwijter-dan-kwijt' kan momenteel toch niet

[CurlyMo]

Sleepie schreef op vrijdag 29 juli 2011 @ 13:41:
[...]
In een RAIDZ2 pool mogen er toch 2 disks uitvallen voor je definitief data kwijt bent?

Klopt. Maar zoals ik eerder zei, ga niet lopen klooien en wacht gewoon even af totdat je die schijf hebt kunnen vervangen. Ik zie het kunnen vervangen van een schijf in een RAID array toch nog altijd als een nood oplossing en niet iets waar je zomaar mee 'speelt'. Maar misschien is dat iets te voorzichtig voor een tweaker

[Sleepie]

Dat ben ik op zich wel met je eens hoor
Maar hoewel geduld een schone zaak is natuurlijk, loop ik daar niet van over

Plus, ik wil in het weekend de series die ik volg nog wel kunnen kijken

[sarcasmemodus]
Mijn disks komen van Azerty....
Ik krijg net een reclame-mailtje van Azerty binnen met als subject "Na regen komt zonneschijn...."
Je zou ze bijna gaan verdenken!!!
[/sarcasmemodus]

[Birdie_NL]

Komt net de pakket man aan de deur, klein pakketje voor u.
Een Norco 4220!

[Verwijderd]

brndst schreef op vrijdag 29 juli 2011 @ 15:02:
Komt net de pakket man aan de deur, klein pakketje voor u.
Een Norco 4220!

goed begin van het weekend

[FireDrunk]

Klein? Hebben ze hem platgestampt bij de TNT?

[Sleepie]

FireDrunk schreef op vrijdag 29 juli 2011 @ 15:17:
Klein? Hebben ze hem platgestampt bij de TNT?

Dan zat mijn disk erin gemonteerd zeker!
Weet ik meteen waarom het hier helemaal fout is gegaan

* Sleepie zit er sterk aan te denken om ook zo'n Norco aan te schaffen trouwens

[ Voor 14% gewijzigd door Sleepie op 29-07-2011 15:18 ]

[FireDrunk]

Vind het ook echt super kasten, maar echt afgrijselijk duur...

[Birdie_NL]

Goedkoop zijn ze zeker niet, alleen het is een zeer mooie basis om te hobbyen.
En je weet wat ze zeggen over hobby's

EDIT: ik plaats dit weekend wel wat leuke foto's.

[ Voor 18% gewijzigd door Birdie_NL op 29-07-2011 15:33 ]

[FireDrunk]

Die mogen geld kosten ja klopt... Maar ik heb al een server grade kast (Chenbro tower) en hotswap bays... Dus nee, voor mij nog even niet

[Sleepie]

FireDrunk schreef op vrijdag 29 juli 2011 @ 15:36:
Die mogen geld kosten ja klopt... Maar ik heb al een server grade kast (Chenbro tower) en hotswap bays... Dus nee, voor mij nog even niet

Jij had die addonics bays toch?

[FireDrunk]

Jup.
* FireDrunk moet nog een keer een paar goede foto's van zijn server maken.

Maar mijn server staat in de kelder, dus belichting is een beetje lastig

[ Voor 95% gewijzigd door FireDrunk op 29-07-2011 15:38 ]

[Sleepie]

Tijdje terug zocht je er nog een geloof ik, heb je ze al compleet?
_{Ik heb er 1 te koop namelijk}

[FireDrunk]

Nee, ben voorzien Heb er zelf binnenkort als het goed is ook een over...

[Stouten]

brndst schreef op vrijdag 29 juli 2011 @ 15:02:
Komt net de pakket man aan de deur, klein pakketje voor u.
Een Norco 4220!

Wat heb je er voor betaald?

[parcifal]

brndst schreef op vrijdag 29 juli 2011 @ 15:32:
Goedkoop zijn ze zeker niet, alleen het is een zeer mooie basis om te hobbyen.
En je weet wat ze zeggen over hobby's

EDIT: ik plaats dit weekend wel wat leuke foto's.

Nice !

ben hier ook trots bezitter van een paar weken nu
zou graag zien / lezen wat je er van maakt

[Verwijderd]

Zijn deze harde schijven van Western Digital model WD15EARS met batchnummer 00Z5B1 compatibel met de Qnap 219+
Indien niet dan wordt het de Synology DS710+

[Verwijderd]

Sleepie schreef op vrijdag 29 juli 2011 @ 11:36:
[...]
Current_Pending_Sectors staat nu weer op 13

Die disk gaat dus gewoon retour .... of kan dit probleem nog een andere oorzaak dan een slechte disk hebben?

Nou nee; als je schijf er telkens Pending Sectors bij krijgt dan lijkt me dat een gemeenschappelijke oorzaak hebben. Dat kan zijn metaal wat vervormd is of stofdeeltjes. Hoe dan ook, die schijf wil je niet meer gebruiken.

Maar heb je nou weer je data toegankelijk? Ook al heb je bad sectors dat betekent niet dat al je data pleite is. Ik zou kalm blijven en deskundig advies inwinnen. Ik heb niet bijster veel ervaring met md-raid, enig advies wat ik je kan geven is niet te haastig gevaarlijke dingen proberen; grote kans dat je je enige kans om je data te recoveren hiermee verspeelt. Je data staat nog steeds op je schijven; totdat jij die vernietigt of er meerdere schijven echt helemaal naar hun grootje gaan.

FireDrunk schreef op vrijdag 29 juli 2011 @ 11:31:
Zeg CiPHER, wat draai je nu zelf eigenlijk? (zowel hardware als software )

Nou zonder te overdrijven past het nog maar net in een vliegtuig hangar. Als ik het zaakje opstart gaan alle straatlichten in de omgeving even zachter branden.

Wel grappig dat sommigen denken dat ik een beest van een config draai; maar dat valt reuze mee. Ik draai natuurlijk ZFS onder FreeBSD. RAID-Z2 met 6 disks en 6 SSDs. Ik heb nog twee backup fileservers met oudere schijven. In totaal wel iets van 40 schijven, maar dan tel ik alles mee. Alleen die 6 disks en 1 in mijn desktop draaien continu. Eigenlijk wil ik het allemaal nog energiezuiniger, dus ik wil graag binnenkort óf Bulldozer/Zambezi platform gaan kopen (zonder videokaart) óf Interlagos met 16 cores en 32GiB UDIMM. Dat laatste alleen als het idle niet teveel gaat schelen. Ik heb al 1.25V DDR3 DIMMs gevonden van G.Skill (SR2) die redelijk betaalbaar zijn. En als Intel de 720 series SSD uitbrengt met 1800MB/s pure write (zonder compressieshit) dan lijkt me dat een mooie aanvulling op mijn huidige 6 Intel SSDs als L2ARC/SLOG.

Enige waar ik van baal is de gigabit ethernet; ik had gehoopt dat 10GBaseT nu allang betaalbaarder was geworden; maar daar is nog nauwelijks iets van terrecht gekomen. CX4 en Fiber wil ik eigenlijk niet. Ik lees wel over dat in 2012/2013 er 10GBaseT LOM chips gaat komen; LAN-on-Motherboard dus. Dat betekent ook dat het energieverbruik sterk zou moeten zijn teruggedrongen. De intel AT2 serveradapters (dualport) zijn al passief gekoeld maar verbruiken in principe nog wel meer dan ik zou willen.

Mijn toekomstvisie is een 10 watt NAS met HDDs die spindown doen en veel SSDs met DIPM die nauwelijks stroom slurpen maar wel 2GB/s+ kunnen doen samen. En die 16 cores met 32 gigabyte DDR3 is ook wel iets waar ik een stijve van krijg, dus dat gaan we ook doen.

[analog_]

Ik wil een NAS bouwen voor een vriend met FreeNAS (lijkt mij zover ik heb bekeken uiteindelijk de meest complete/gebruikersvriendelijk NAS oplossing). Zijn er nog dingen die ik op hardware gebied met deze keuze niet moet vergeten. Gevoelsmatig is de huidige config een beetje overpowered, suggesties om het geheel eventueel wat zuiniger te krijgen met simpele ingrepen?

#	Product	Prijs	Subtotaal
5	Seagate Barracuda Green 5900.3, 2TB	€ 58,90	€ 294,50
1	Lian Li PC-Q08B	€ 88,90	€ 88,90
1	Intel Core i3 2100	€ 89,-	€ 89,-
1	Kingston ValueRAM KVR1333D3N9K2/8G	€ 37,25	€ 37,25
1	Asus P8H67-I	€ 85,91	€ 85,91
Bekijk collectie Importeer producten		Totaal	€ 595,56

[FireDrunk]

16 cores, 32GB, en dan 10W? Daar krijgt iedereen toch een stijve van?

Die Intel NIC's verbruike 5-20W afhankelijk van de gegarandeerde kabelafstanden...

Zo gek is dat toch niet? De lichste gebruikt 4.6W.

Ze zijn wel duur ja.. (> € 500,- )

[ Voor 55% gewijzigd door FireDrunk op 29-07-2011 17:22 ]

[Verwijderd]

@analog_
Je kunt vergelijken met mijn low power ZFS NAS lijstje:

#	Product	Prijs	Subtotaal
1	Asus E35M1-I	€ 100,-	€ 100,-
6	Samsung Spinpoint M8 1000GB, 1TB SATA-300, 8MB, 5400rpm	€ 72,-	€ 432,-
1	Mini-box picoPSU 90 + 80W Adapter Power Kit	€ 55,22	€ 55,22
1	G.Skill F3-12800CL9D-8GBSR2	€ 66,90	€ 66,90
Bekijk collectie Importeer producten		Totaal	€ 654,12

Ik ken die Seagate 5900.3 schijven overigens niet; ik hoop dat die ook 666GB platters gebruiken? Mijn eigen voorkeur zou de Samsung F4EG zijn die 140MB/s doen wat volgens mij de snelste 2TB schijf is op 5400rpm; en ook zuiniger qua spinup current. Bovenstaand lijstje kun je opdelen in:
- ander moederbord en CPU: brazos platform is zuiniger maar minder krachtig, wel goedkoper
- 1TB Samsung M8 notebook hardeschijven zijn grofweg 2x zo duur als desktopschijven, maar wel flink zuiniger en maakt het mogelijk een PicoPSU voeding te gebruiken voor extra zuinigheid
- 1.25V DDR3 geheugen is ook extra zuinig (ik weet niet 100% zeker of dat moederbord deze DRAM ook accepteert; maar ik mag aannemen van wel?)

@FireDrunk
Nouja Interlagos en Zambezi zijn AMD's eerste High-K Metal Gate processoren, samen met Llano die al uitgebracht is. Dat zou betekenen dat met een 100W+ TDP de CPU idle maar een paar watt slurpt. Dus je hebt een extreem groot verschil tussen idle en stressed verbruik. Dat is precies wat ik wil: veel power maar idle extreem zuinig zodat ik een zuinige 24/7 NAS heb. En 32GiB RAM betekent dus 8 reepjes van 1.25V; dat zou ook best mee moeten vallen. Maar ook met 20W ben ik content; 10W zou mijn natte droom zijn voor zo'n high-end setup.

[FireDrunk]

Ik draai idle 61W, en dat vind ik al redelijk, ik verwacht niet dat je ooit op 20W komt (met zo'n setup)...
Vooral omdat je voeding natuurlijk al dat vermogen wel moet kunnen leveren...

Dus totdat de voedingen dat zelfde [zuinig @ idle vs power @ load kunstje] kunnen, blijft het een droom...

[Verwijderd]

PicoPSU + notebook schijven + DIPM SSDs

[analog_]

De vraag is vooral of een i3 2100 nodig voor wat ik wil doen of volstaat een simpelere oplossing (al dan niet AMD). Wat is conventioneel gezien de meest stabiele config met FreeNAS want ik weet dat bijvoorbeeld ZFS erop kan echter veranderd dat wel wat aan je hardware eisen. Ik heb de disks en het ram veranderd in wat CiPHER adviseerde.

[Verwijderd]

Voor die notebook disks gaan zou ik alleen doen als je PicoPSU wilt draaien. Dan 'moet' je ook voor het Brazos platform gaan om daadwerkelijk profijt te hebben van die keuze. Dan zou je een erg low-power NAS setup krijgen. 2TB Samsung F4EG zou ook kunnen; die doen zo'n 16W spinup. Maar dan zit je met 4 van die schijven eigenlijk aan de max van een 90-100W PicoPSU en heb je aan een 80W +12V adapter al niet genoeg. Dus daarom dat die notebook schijven met 4W spinup interessant zijn. Dan kun je rustig 10 van die schijfjes kopen.

Weet wel dat add-on controllers niet altijd goed werken met de Brazos bordjes; alhoewel sommige Asus bordjes wel een BIOS update hebben gekregen die LSI 1068E kaarten mogelijk maakten voor extra schijven.

Het is een afweging hoe belangrijk low idle power voor je is. Voor mij is het ook een beetje sport en interesse; het praktisch nut moet worden afgezet tegen de hogere aanschafkosten.

[Verwijderd]

Een H61/H67 + G620 combinatie zou ook een watt of 14 moeten kunnen halen, ik ga zelf het brazos platform dan ook links laten liggen en kies voor de G620 combi. Die heeft toch net even wat meer power voorhanden