mdadm array om zeep?

[Demo]

Vanochtend is hier in het dorp de stroom uitgevallen en aangezien ik mijn UPS niet verbonden heb met mijn server, is die nogal hardhandig uit gegaan toen de UPS eenmaal leeg was.
Nou heb ik het ding weer aangezet, maar de Samba-shares wilden niet echt meewerken. Ik zag wel mappen en wat bestandjes, maar niet alles wat er hoorde te staan. Daarop ben ik ingelogd op de server, heb de mdadm RAID5-array geünmount, fsck geprobeerd, maar die liep te klagen over een superblock.
Daarop heb ik een reboot gedaan en toen was de hele array niet meer te vinden Als ik nu mdadm --assemble --scan doe, krijg ik:
mdadm: /dev/md0 assembled from 2 drives - not enough to start the array.
Maar bij een ls /dev zie ik wel sdb t/m sde staan - de schijven die samen de array moeten vormen.

cat /proc/mdstat geeft:

code:

Personalities :
md0 : inactive sde[0](S) sdc[3](S) sdb[2](S) sdd[1](S)
      3907049984 blocks

Doorgaans ga ik zelf graag aan het knoeien om probleempjes op te lossen, maar ik f*ck liever niet met 2,5 TB aan data (ja het meest belangrijke is gebackupt, maar toch) dus liever vraag ik jullie in deze om hulp.

[kalizec]

Zoals ik het lees heb je vier schijven in dat systeem zitten en zijn er maar 2 beschikbaar. (Waarom heb je echt meer informatie voor nodig). Je hebt er minimaal drie nodig om je data beschikbaar te krijgen.

[Nvidiot]

http://linux-raid.osdl.org/index.php/Linux_Raid Daar staat wellicht iets nuttigs, zo niet, probeer dan de linux-raid mailinglist. Ik zie daar regelmatig mensen voorbij komen met vergelijkbare vragen en die worden over het algemeen goed geholpen door de developers op de lijst

[Verwijderd]

Mhhh... alles is spare zo te zien ?

Ik denk dat je even een pro-tool je array op moet laten zoeken of een paar keer rebooten.

Wat had je... raid5 ? ja dus


Je kunt ook even booten met knoppix of je reque CD van je distro.. deze zou alles moeten kunnen zien met een beetje geluk.

[ Voor 32% gewijzigd door Verwijderd op 01-04-2009 23:09 ]

[Demo]

Nvidiot schreef op woensdag 01 april 2009 @ 23:07:
http://linux-raid.osdl.org/index.php/Linux_Raid Daar staat wellicht iets nuttigs, zo niet, probeer dan de linux-raid mailinglist. Ik zie daar regelmatig mensen voorbij komen met vergelijkbare vragen en die worden over het algemeen goed geholpen door de developers op de lijst

Met de info van die wiki een mdadm --assemble --force geprobeerd. Nu heb ik het volgende:

code:

[root@htpc ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sde[0] sdb[3] sdc[2]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]

unused devices: <none>

Heb met hdparm nog wat dingen aan /dev/sdd gevraagd en die reageert gewoon. Dus waarom die nou uit de array ligt?
Zou het kwaad kunnen om deze uit de array te gooien en als spare weer toe te voegen?

[Demo]

Nadat ik zojuist een mdadm --add /dev/md0 /dev/sdd had geprobeerd kreeg ik de melding "Re-added /dev/sdd" en nu de volgende output van /proc/mdstat

code:

md0 : active raid5 sdd[4] sde[0] sdb[3] sdc[2]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]
      [>....................]  recovery =  0.0% (710784/976762496) finish=274.6min speed=59232K/sec

Array is dus aan het rebuilden, kan nu met een gerust hart gaan slapen en morgen mijn data weer tevoorschijn toveren.
* Demo haalt opgelucht adem, dataproblemen zijn erg slecht voor nachtrust en concentratie

[Verwijderd]

Demoniac schreef op vrijdag 03 april 2009 @ 00:33:
Nadat ik zojuist een mdadm --add /dev/md0 /dev/sdd had geprobeerd kreeg ik de melding "Re-added /dev/sdd" en nu de volgende output van /proc/mdstat

code:

md0 : active raid5 sdd[4] sde[0] sdb[3] sdc[2]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]
      [>....................]  recovery =  0.0% (710784/976762496) finish=274.6min speed=59232K/sec

Array is dus aan het rebuilden, kan nu met een gerust hart gaan slapen en morgen mijn data weer tevoorschijn toveren.
/me haalt opgelucht adem, dataproblemen zijn erg slecht voor nachtrust en concentratie

Hoezo morgen ? Je zou je data nu al moeten kunnen zien....

Als je array gerebuild moet worden als je niets kunt zien... zul je ook nooit meer iets van je data zien.

[Ventieldopje]

Ligt er aan wat voor RAID je gebruikt, als je RAID 5 gebruikt heb je grote kans dat je je data nog weer terug krijgt, echter in RAID0 kun je donderop zeggen dat alles foetsie is.

[Demo]

Woei

code:

[root@htpc ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdd[4](S) sde[0] sdb[5](F) sdc[2]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/2] [U_U_]

Nu is er dus een andere gefaild en ziet ie sdd nog steeds als spare... erg frustrerend dit!

[ph0t0nix]

Heb je al geprobeerd om met de smartmontools te kijken of je disks nog in orde zijn?

[Nvidiot]

Kon je bij de data op de array toen je de array van 3 disks had? Kon dat niet dan was de rebuild niet zo heel fijn...

[Verwijderd]

Als een raid5 set crasht kunt je deze niet rebuilden met dezelfde disks... dat is echt onmogelijk !!

Je kunt alleen je array rebuilden als je raid5 set nog bestaat maar een drive eruit ligt volgens je fault-tollerantie.

MIjn inziens ben je je data kwijt !

[Demo]

Nvidiot schreef op vrijdag 03 april 2009 @ 08:48:
Kon je bij de data op de array toen je de array van 3 disks had? Kon dat niet dan was de rebuild niet zo heel fijn...

Heb ik niet geprobeerd, bij het mounten kreeg ik meldingen dat het filesystem eerst gefsckt moet worden en dat wilde ik liever doen op het moment dat de array gered is.

Verwijderd schreef op vrijdag 03 april 2009 @ 09:01:
Als een raid5 set crasht kunt je deze niet rebuilden met dezelfde disks... dat is echt onmogelijk !!

Je kunt alleen je array rebuilden als je raid5 set nog bestaat maar een drive eruit ligt volgens je fault-tollerantie.

MIjn inziens ben je je data kwijt !

Als er een schijf uitgespuugd is door de array, maar die schijf lijkt verder nog in orde, dan kan je daar prima op rebuilden..

[Verwijderd]

Demoniac schreef op vrijdag 03 april 2009 @ 10:55:
[...]
Als er een schijf uitgespuugd is door de array, maar die schijf lijkt verder nog in orde, dan kan je daar prima op rebuilden..

Klopt, maar je wekt het idee dat je zonder die rebuild niet bij je data kan.... dat is niet waar.

[PowerSp00n]

Ik heb alleen nog maar mdstat knipsels gezien eigenlijk, wat zeggen je logs? Zijn er read/write errors op een of meerdere disks? Heb je al Drive Fitness Test (achtige) tools gedraait om te controleren wat de werkelijke staat van de schijven is? Het lijkt me toch wel handig op z'n minst deze informatie te hebben om te kunnen bepalen waar je probleem zit, als er inderdaad 2 of meer schijven echte problemen hebben zakt de kans om (alle) data terug te krijgen aanzienlijk.

[Verwijderd]

PowerSp00n schreef op vrijdag 03 april 2009 @ 17:06:
Ik heb alleen nog maar mdstat knipsels gezien eigenlijk, wat zeggen je logs?

Ik denk eerder dat hij geen notie heeft van waar hij mee bezig is... opzetten tijdens de install is simpel... commandline iets lastiger voor sommigen.

[Demo]

Als ik wist wat ik deed, had ik het hier niet gepost he Drive fitness tools wil ik best draaien (hell, ik zou mijn sokken opvreten om die array te redden) maar zolang er niet verteld wordt wat ik moet installeren en draaien, wordt dat lastig..

Stukje error.log:

code:

Apr  3 19:37:50 htpc kernel: ata3.00: cmd 60/d8:60:00:aa:dc/00:00:02:00:00/40 tag 12 ncq 110592 in
Apr  3 19:37:50 htpc kernel: res 41/40:00:0a:aa:dc/ea:00:02:00:00/40 Emask 0x409 (media error) <F>
Apr  3 19:37:50 htpc kernel: ata3.00: status: { DRDY ERR }
Apr  3 19:37:50 htpc kernel: ata3.00: error: { UNC }
Apr  3 19:37:54 htpc kernel: ata3.00: exception Emask 0x0 SAct 0x7fff SErr 0x0 action 0x0
Apr  3 19:37:54 htpc kernel: ata3.00: irq_stat 0x40000008
Apr  3 19:37:54 htpc kernel: ata3.00: cmd 60/d8:10:00:aa:dc/00:00:02:00:00/40 tag 2 ncq 110592 in
Apr  3 19:37:54 htpc kernel: res 41/40:00:0a:aa:dc/ea:00:02:00:00/40 Emask 0x409 (media error) <F>
Apr  3 19:37:54 htpc kernel: ata3.00: status: { DRDY ERR }
Apr  3 19:37:54 htpc kernel: ata3.00: error: { UNC }
Apr  3 19:37:54 htpc kernel: end_request: I/O error, dev sdb, sector 48015882

Het lijkt er dus inderdaad op dat /dev/sdb een probleem heeft...

[Verwijderd]

Waarom wil je die array redden ? Je data is weg aangezien je array defect is.

Je kan er raidtools op los laten, ik geef je echter weinig kans.

Ga eerst eens lezen wat raid nu eigenlijk inhoudt en wat de fouttollerantie is per raid-level.

Als er maar 1 HD defect is zou je zo bij je data moeten kunnen... je array zal altijd rebuilden nu... hoe dan ook... je data is gewoon foetsie als je mij vraagt.

Ik snap best dat je hier post omdat je niet weet wat er aan de hand is... het probleem is dat je de basis van Raid/Linux Softraid niet kent... en daarom gaat het mis.

Raid != backup... die had je namelijk moeten maken

Ik denk overigens dat je HD al uit die array heeft gelegen voor de stroomuitval... echter zal je de notificatiemails wel uit hebben staan ?

[ Voor 10% gewijzigd door Verwijderd op 03-04-2009 21:52 ]

[Demo]

Ik weet prima wat verschillende RAID-levels inhouden hoor. Waar het mij om gaat, is dat mdadm er niet helemaal over uit lijkt te zijn wát er nou mis is. Ik ben er ook van op de hoogte dat RAID geen backup is en zoals ik in mijn startpost al vertelde is het meest belangrijke ook gebackupt, maar dat betekent niet dat ik de rest van de data wil afschrijven als de kans bestaat dat het nog te redden is. Ik weet wat een spare is en wat de array gaat doen als er een faulty drive is (heb 2 jaar een Areca gehad, die begon op het laatst schijven uit te spugen) maar dan was het ook heel consequent stuk of werkend. Vandaar dat dit me in verwarring brengt.

[Verwijderd]

Je vergelijkt appels met peren omdat je niet weet hoe een array is opgebouwd.

Ik zeg... schijven los en een raidtool welke md ondersteunt... anders... tja.. ik denk hele vette pech.

[Verwijderd]

De (S)'jes achter de mdstat output in je eerste post betekent dat die schijfen als spare zijn herkent. iets wat aangeeft dat je superblocks waarschijnlijk niet in sync zijn. Mdadm geeft ook aan dat maar 2 van de 4 schijfen in sync zijn en dat mdadm onzeker is over sdb en sdd. In Raid5 moeten alle schijfen - 1 in sync zijn dus om deze 4 set Raid5 te starten heb je minimaal 3 schijfen nodig.

Toen je daarna de assamble hebt geforce'd heeft mdadm eigenlijk een best guest gedaan en de array gestart blijkbaar met sde, sdc en sdb.

Nou dit is belangrijk: Heb je toen gekeken of dat het je de partitie kon mounten? zo ja dan was mdadm correct en is alleen sdd out-of-sync. Door sdd toe te voegen aan de array werd sdd weer in sync gebracht met de rest. Zo niet dan werd de juiste data op sdd overschreven met de rommel van sdb.

Een array die als active wordt gezien in /proc/mdstat kan gewoon gebruikt worden. Zelfs als deze aan het syncen of rebuilden is en omdat hiervoor de idle bandwijdte wordt gebruikt heb je hier nauwlijkst last van.

Het probleem is echter de dat daarna ook sdb crashte. Je had echter waarschijnlijk -re-add moeten gebruiken want waarschijnlijk was je nu je raid5 van 3 naar 4 disks aan het growen. Was dit eigenlijk een 3 of een 4 disk array? anyway, ga inderdaad eerst je schijfen goed testen want sdb crashte niet zomaar.

Als je schijfen goed zijn probeer dan eerst de array te starten met alleen sde en sdc. Mocht dit werken dan heb je inderdaad een 3 disk raid5. Zo niet probeer het dan nog eens met sdd erbij. Probeer dan eerst een read-only fsck. Als fsck het filesystem op de array nog herkent dan heb je nog een goede kans dat je data ok is. doe daarna eerst een complete fsck met om te zorgen dat je filesystem in orde is. voeg daarna sdb toe en volg het syncen in /proc/mdstat.

Als fsck de filesystem headers niet meer herkent dan kun je het eigenlijk wel opgeven. Je zou met recovery tools nog bestanden ervan af kunnen proberen te plukken. Sommige tools zijn raid-aware en kunnen zelfs van beschadigde en out-of-sync schijven nog wat bestanden ontdekken maar aangezien je een backup hebt kun je beter gewoon de boel opnieuw formatteren en met een schone array beginnen.

Tip1
Het is trouwens beter om op elke schijf 1 grote partitie van het type 0xfd te maken ipv de hele schijf te gebruiken. Andere systemen weten dan teminste dat die schijf bij een software raid hoort en hem niet als ongeformateerd beschouwen omdat een partitie tabel ontbreekt. Vooral windows wil dan je superblock overschijfen met een lege partitie tabel omdat deze denkt dat je een net gekochte nieuwe schijf in het systeem hangt.

Tip2
Je had dit probleem mischien goeddeels kunnen voorkomen door een goede mdadm.conf bij te houden. Hoewel de schijfen elk een superblock hebben met de configuratie kan dus als die superblocks out-of-syncen raaken de array worden opgebouwd middels de backup config in /etc/mdadm/mdadm.conf.

Om een initiele config te maken van de huidige actieve arrays:
mdadm --scan --detail >> /etc/mdadm/mdadm.conf

Vergeet niet om dit bestand daarna te inspecteren en waar nodig aan te passen. Het vertelt het systeem welke arrays er zijn, welke schijfen daarbij horen en of ze spare zijn of niet. Elke keer dat je je een schijf van je array verwijdert of toevoegt moet je deze config updaten zodat ook zonder superblocks je array startbaar is.

Tip3
Lees de man page van mdadm. Zeer informatief en te vinden met het commando: man mdadm.

[Demo]

Wow, wat een antwoord.. bedankt Uitgaande van jouw post vrees ik wel dat ik mijn data kwijt ben. /dev/sdc en /dev/sde is te weinig om te starten, maar /dev/sdd wordt gezien als spare en daarmee kan dus ook niet gestart worden. /dev/sdb is faulty en dus ook niet bruikbaar om te starten.
Is het hoe dan ook mogelijk om aan te geven dat er met een faulty drive (/dev/sdb) toch gestart wordt, met het risico dat niet alle data consistent is? Het maakt me niet eens zoveel uit als ik een hoop kwijt ben, als ik maar weet wát ik kwijt ben.. Zijn er livecd's die voorzien in essentiële tools voor het redden van data?

Betreft je tips:
Tip 1 had ik al ontdekt, heb eerst test gedraaid met de schijven aan een VM en toen wilde Windows inderdaad telkens die disken initialiseren. Dat gebeurt gelukkig niet automagisch en het systeem waar ze nu in hangen draait maar één OS dus is dat risico ook minimaal. Neem 'm wel mee voor een nieuwe array.
Tip 2 is ook een goeie voor de toekomst, ik heb in mdadm.conf alleen maar ARRAY /dev/md0 level=raid5 num-devices=4 UUID=... staan. En wat zou ik dan moeten inspecteren/aanpassen?
Tip 3, de manpage van mdadm heb ik de afgelopen dagen al tientallen keren voor mijn neus gehad. Echter is het als newbie op dit gebied niet even begrijpelijk

[Verwijderd]

Waarom heb je nu nog steeds niet gezocht voor een raidtool welke MD ondersteunt ?

Dat je je data in je huidige set kwijt bent had ik je al eerder verteld... en als een raidtool er niets meer aan kan doen kan dit zeker komen omdat je zelf zo maar een disk aan je array hebt toegevoegd waarna hij ging rebuilden.

Raid sets is uitlezen... nooit iets anders mee doen na zo'n crash !

[Verwijderd]

Probleem met corruptie van een raid array is dat de schade volgens het zelfde patroon als de array zelf gaat. Dus in bijvoorbeeld een Raid0 van 2 schijfen waarin schijf 2 mist ontrbeekt elk 2e of even stuk. Je data, dus ook de filesystem headers zijn een gatenkaas waarin mischien telkens 1 of 2 stukken van sde en sdc kloppen gevolgd door verstoorde of missende data van sdd en sdb.

Mischien heb je geluk en was de schade veroorzaakt door het geforceerd sync'en met de verkeerde schijf en omdat dit mogelijk niet helemaal voltooid was is aan het einde van je array nog wat onbeschadigde data te vinden maar alleen met een md-aware recovery tool zal je dit kunnen bewijzen.

Je kunt mogelijk door op de schijf een gehackt superblock te zetten mdadm erin luisen dat deze nieuwe en foute schijf een onderdeel van de array is en zo met 3 schijfen starten. De superblocks zijn hier tegen beschermd door elke array een uniek UUID dus je zult zelf met een hex editor ofzo dit moeten opzetten. Maar omdat de parity informatie op deze nieuwe schijf natuurlijk niet klopt en mdadm onterecht denkt dat deze schijf een onderdeel van de array is door de gefakede superblock kan mdadm aan syncen slaan en wat er nog op sde en sdc mocht staan vernielen. Dit is dus echt niet aan te raden.

Als je nog wat wilt redden zul je met een raid bewuste recovery tool byte voor byte op zoek moeten gaan naar restanten van bestanden. Als je de ruimte ervoor hebt zou je eerst een image kunnen maken van je schijfen en daarop werken. Je kunt dan ook alvast je backup terug zetten en dan heb je je samba in iedergeval weer draaien.

Ik heb zelf gelukkig nog nooit een recovery tool hoeven gebruiken dus probeer google eens. Ik heb gehoord dat er een linux recovery tool is die md-aware is maar ben de naam ervan kwijt. Ook de mdadm.conf backup heb ik gelukkig nog nooit nodig gehad maar ik maak gewoon altijd even een configuratie backup als ik mijn array's aanpass. Ik zie dat mijn (Debian) server zelfs de mdadm.conf als opstart configuratie gebruikt in init.

Volgensmij staat elke entry in de config voor de array naam, hoeveel devices in totaal en hoeveel spares. Welke raid type er wordt gebruikt en dus de UUID van de array. Vervolgens worden dan gewoon alle schijfen in het systeem gescan'd voor een superblock met dat UUID. Op de superblock staat dan zelf iets als ik hoor bij array met UUID en ben schijf 2 bijvoorbeeld. Vergeet niet de oude lijnen uit je config te halen als je de nieuwe toevoegt, in vi door 2x d te tikken. Ook kan een cp geen kwaad. Hier is mijn (oude) mdadm.conf als voorbeeld.

code:

#scan devices by superblock
DEVICE partitions

#default create permissions
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST <system>

#send mail to:
MAILADDR root

#Disk 1 is 4x320gb  raid0 at sda, sdb, sdc, sdd.
#Disk 2 is 3x500gb  raid5 at sde, sdg, sdf.
#Disk 3 is 2x1024gb raid0 at sdh and sdi.
ARRAY /dev/md0 level=raid0 num-devices=4 UUID=65925a36:ce84f999:dfc28f36:a77cc27b
ARRAY /dev/md1 level=raid5 num-devices=3 UUID=c303b085:39054680:bd4d965f:5fd1bf74
ARRAY /dev/md2 level=raid0 num-devices=2 UUID=9966f2ed:00cf5520:bd4d965f:5fd1bf74

[Demo]

Twee weken later, heb de hoop op het terugkrijgen van m'n data allang opgegeven maar nog geen nieuwe array aangemaakt.
Gezien de kennis van mdadm die hier in een aantal reacties tentoongespreid wordt, wil ik graag even vragen wat de meest optimale settings zouden zijn voor een nieuwe array. Zowel voor mdadm (chunk size) als het filesystem wat er overheen gelegd wordt.
Ik heb zelf natuurlijk wel wat zoekwerk verricht, maar bij wat ik vind is meestal geen sprake van dergelijke grote array's.. Daarnaast is ext4 natuurlijk vrij recent in de distro's opgenomen en wordt daarom ook niet of nauwelijks genoemd.

[Verwijderd]

De vraag is nog steeds of je de manual gelezen hebt.

De standaard chuck-size welke mdadm instelt voor raid5 is prima... het ligt aan je app/data of je een grotere of kleinere wil.

Ik ken mensen met 12 disken ala 1TB + mdadm en google weet er ook wel wat over te vertellen.

De vraag die ik mij blijf stellen is of je wel weet wat je doet en als je het doet of je dan wel de juiste documentatie leest.

Het komt wat betweterig over wellicht maar ik kan je geen ander advies geven dan back to basics en meer goede documentatie te lezen.

Maak tevens backups volgende keer

[Verwijderd]

Demoniac schreef op dinsdag 14 april 2009 @ 15:12:
Daarnaast is ext4 natuurlijk vrij recent in de distro's opgenomen en wordt daarom ook niet of nauwelijks genoemd.

Ik zou afhankelijk van de gemiddelde bestandsgrootte voor ext3 of xfs kiezen. Met ext4 zou ik gewoon nog lekker een jaartje wachten want het is allemaal net iets te nieuw en er komen langzaam al diverse ext4 bugs naar boven.

[Verwijderd]

Verwijderd schreef op dinsdag 14 april 2009 @ 18:17:
[...]


Ik zou afhankelijk van de gemiddelde bestandsgrootte voor ext3 of xfs kiezen. Met ext4 zou ik gewoon nog lekker een jaartje wachten want het is allemaal net iets te nieuw en er komen langzaam al diverse ext4 bugs naar boven.

Wellicht heeft dit ook iets met de ontwetendheid van de TS te maken.

Als we hem hier nu eens mee helpen dan komt het wellicht goed.

Als startpunten is het dus denk ik handig om:

- Manual goed te lezen en weten wat je doet. Alles wat door scripts wordt gedaan is dan alleen handig... je vergemakkelijkt de basics dus.
- Proven zaken te gebruiken als ext3. Nieuw en flashy betekent niet altijd dat het heel goed is, te oud is ook niet altijd handig
- Testen opzetten met HW die je hebt en de voordelen van je chunk-size zien doormiddel van benchmarks bijvoorbeeld.

[Verwijderd]

Ik heb wat filesystem benchmarks voor de topic starter gevonden. Dat is nuttig leesvoer om mee te beginnen denk ik zo

"#4 Linux filesystem benchmark 2008/2,"
http://www.t2-project.org/zine/4/

"#1 Linux filesystem benchmark 2008/1,"
http://www.t2-project.org/zine/1/

"Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch,"
http://www.debian-administration.org/articles/388

"File system references," a good number of articles with regard to file systems' benchmark, description, and features:
http://www.sabi.co.uk/Notes/linuxFS.html#fsRefs

He also has several note worthy benchmarks,
http://www.sabi.co.uk/blog/anno05-3rd.html#050913
http://www.sabi.co.uk/blog/anno05-3rd.html#050908
http://www.sabi.co.uk/blog/anno06-2nd.html#060416

"Benchmarking Filesystems Part II," this is apparently an article that has been commented and referenced by large:
http://linuxgazette.net/122/piszcz.html

"SOME AMAZING FILESYSTEM BENCHMARKS,"
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm

"Comparaison des systèmes de fichier ReiserFS, Ext3, Jfs et Xfs", (Comparison of file systems ReiserFS, Ext3, JFS and XFS) -- mostly with regard to CPU utilization,
http://arnofear.free.fr/linux/files/contrib/bench/bench.html

"First benchmarks of the ext4 file system,"
http://www.linuxinsight.c...the_ext4_file_system.html

[ Voor 4% gewijzigd door Verwijderd op 14-04-2009 19:03 ]

[Demo]

Verwijderd schreef op dinsdag 14 april 2009 @ 18:36:
- Manual goed te lezen en weten wat je doet. Alles wat door scripts wordt gedaan is dan alleen handig... je vergemakkelijkt de basics dus.

Ik snap niet wat ik nou moet begrijpen In de manpage staat weinig nieuws. Hoe RAID5 werkt begrijp ik, dat een array met 2 dode schijven niet meer te redden is snap ik ook, maar ik had in eerste instantie het vermoeden dat mdadm iets in de soep had laten lopen, ipv dat er echt schijven dood waren.. en dat is wat mij betreft al geen basics meer. (een dooie schijf vervangen en een array rebuilden, dat is basic)

- Proven zaken te gebruiken als ext3. Nieuw en flashy betekent niet altijd dat het heel goed is, te oud is ook niet altijd handig

Dat is een tip waar ik iets mee kan Ik heb mijn array destijds aangemaakt in ext4 omdat dat er op papier veel beter uitzag dan ext3, zeker voor een volume van dergelijke grootte. Dat er nog bugs zouden zitten had ik niet verwacht (waarom zijn ze dan van ext4-dev naar ext4 gegaan?) mede omdat het een 'evolutie' van ext3 is. XFS is me ooit heel erg hard afgeraden door iemand die naar mijn idee meer van Linux afweet dan ik zelf, dus dat heb ik maar voor waar aangenomen.

- Testen opzetten met HW die je hebt en de voordelen van je chunk-size zien doormiddel van benchmarks bijvoorbeeld.

Uiteraard, maar daar gaat een hoop tijd in zitten en bovendien zeggen de ervaringen van medetweakers in real-life situaties me meer dan de uitkomsten van een syntetische benchmark. De optimale chunk/block size voor een volume waar vooral grote bestanden op komen zal bij mij niet veel anders zijn dan bij een willekeurige andere tweaker

Verwijderd schreef op dinsdag 14 april 2009 @ 18:59:
Ik heb wat filesystem benchmarks voor de topic starter gevonden. Dat is nuttig leesvoer om mee te beginnen denk ik zo

...ik heb morgen wat te lezen, bedankt

[Verwijderd]

Ik heb zelf nooit echt met de chunk size gespeeld vooral omdat met de standaard settings ik mijn gigabit netwerk al makkelijk voltrek over ftp en zeker over samba.

Wat ik ervan begrijp is de chunk size eigenlijk de minimale grote van een write naar een disk in de array is. Dus als je een chunk-size van 2 kilobyte hebt en je schrijft 8 kilobyte naar een raid array van 4 schijfen dan komen de eerste 2 kilobyte of schijf 1 terecht. Kilobytes 3 en 4 op schijf 2. 5 en 6 op schijf 3 en de laatste 2 op schijf 4.

Normaal heb je niks aan die info tenzij je weet hoe de bovenliggende informatie verdeeld is in het bestandsysteem. Gelukkig heeft Ext2 en later de stride optie waarmee die een vergelijkbare optie biedt voor het bestandsysteem als de chunk-size voor de array doet. Zie ook de Software-RAID-HowTo voor meer uitleg.

Als je dus een Raid5 hebt met 3 schijfen en je zet de chunk size op 64kb dan wordt een write van 128kb precies verdeelt over alle 3 de chunks namelijk 2x 64kb + 64kb parity. Je moet dan alleen wel zorgen dat je filesystem ook goed allign'd is zodat het precies uitkomt. Hierdoor heb je minder overhead vooral in Raid 4,5,6.

Ext4 is inderdaad de toekomst en daarna btrfs waarschijnlijk maar Ext4 is nu echt nog maar net af. Debian, welke toch altijd wat conservatiever is en de lat hoog legt kwa kwaliteit en stabiliteit ondersteunt Ext4 bijvoorbeeld nog niet out-of-the-box en de recente data-loss probelemen bewijzen dat ook wel. Ext4 heeft nog heel wat bugs die geplet moeten worden. Voor nu is Ext3 toch echt nog het beste kwa stabiliteit maar Ext4 is inderdaad wel de experimentele fase voorbij maar productie klaar zou ik het nog niet willen noemen. Geschikt voor desktop werk maar voor bedrijfskritische servers zou ik nog bij Ext3 blijven en Ext4 nog een jaar laten rijpen.

XFS biedt een aantal mooie features welke vooral mooi samenwerken met LVM bijvoorbeeld. XFS is een beetje een outsider. Hoewel zeker geen slecht systeem en beter dan Ext4 of ReiserFS op het moment kwa stabiliteit en betrouwbaarheid. Het is oorspronkelijk nooit voor Linux ontwikkeld en dat maakt sommige die-hards wat skeptisch en argwanend. De eerste versie's van de port naar Linux waren dan een paar jaar geleden ook nog van experimentele kwaliteit maar XFS mag nu anno 2009 wel volwassen worden genoemd en een gedegen concurrent van Ext3. XFS was oorspronkelijk door SGI ontwikkeld voor IRIX.

Een belangrijk punt wat vaak wordt vergeten met Raid is dat je failure rate ook toeneemt met het aantal schijfen. Je hebt immers normaal alle schijfen in je array nodig en met elk schijf die je toevoegt neemt de kans dat een schijf crashed dus ook toe. Zelf draai ik Raid6 met 5 500GB schijfen welke dus 2 doode schijfen nog kan overleven ipv 1 zoals met Raid 5. Ook heb ik altijd 1 spare schijf op 'voorraad' die ik kan gebruiken terwijl ik een doode schijf opstuur voor RMA zodat de kans op een drievoudige crash wel heel klein is geworden en met de prijs van 500GB sata schijfen is dat een best betaalbare oplossing zo'n 5 + 1 cold spare.

Kortom ik zou gewoon de default chunk-size gebruiken met Ext3 op Raid5 en je trekt je netwerk al vol.

[Borromini]

Wat Ext4 betreft moet ik de meesten hier bijtreden - ik ga er géén server op draaien (zelfs m'n eigen laptop niet - ik vergooi m'n tijd niet met reformats en clean installs). Migratie van ext3 naar ext4 kan soms falikant aflopen qua performance, en dan moet je wel een format doen, en dataverlies met ext4 is nog schering en inslag. Dan denk ik dat reiser4 stabieler is - en dat zal nooit in de mainline kernel meer raken .

Ext4 is zoals gezegd nog lang niet klaar voor productie - althans niet op de manier dat Ext3 en ReiserFS het bv. zijn. Persoonlijk bekijk ik distro's die het standaard als FS zullen gebruiken (er was een mainstream distro die dat vrolijk ging implementeren) met argusogen, maar dat moeten ze (en de gebruiker, bij uitbreiding) maar zelf weten. Ik wil gerust wel een kernel RC draaien (en doe dat ook af en toe), maar een bestandssysteem is een ander paar mouwen.

[Demo]

Docey: voor zover ik weer zorgt een grotere chunk-size niet voor meer overhead, in tegenstelling tot een grotere block-size in je filesystem. Aangezien je chunks altijd groter horen te zijn dan je blocks. Je moet alleen een beetje een balans vinden tussen teveel heen en weer springen tussen disken (te kleine chunks) en te grote reads/writes tegelijk willen doen (te grote chunks) om de optimale snelheid te halen.

Borromini: dat was precies mijn idee, een beta/RC kernel/app die een keer bugt kan niet zoveel kwaad, maar filesystems moeten niet gaan lopen buggen! Ik volg de wijze raad hier op en ga voor ext3

[Verwijderd]

Als je chunk-size maal het aantal schijfen min 1 of 2 groter is dan de block-size van je filesystem dan betekent dit voor raid4, 5 en 6 wel degelijk meer overhead omdat je dan een read-modify-write doet ipv een simpele write.

Voorbeeldje: je hebt een raid6 met 6 schijven. 2 schijven dus voor parity en 4 voor data. De chunk-size is 640kb en de block-size van je filesystem is 1024kb. Als je dus 1024kb naar je filesystem schrijft dan komt dus maar 256kb daarvan op de array per schijf terecht en moet dus eerst de overige 386kb worden ingelezen om de parity te berekenen van de hele chunk van 640kb waarvan dus 256kb nieuw en 386kb oud. Dit heet een read-modify-write cycle en is veel langzamer omdat je data in 2 richting per schijf moet sturen.

Als je chunk-size daarintegen 512kb is en je filesystem 2048kb dan zal een write van 2048kb precies op de chunk-size passen en worden er gewoon 6 writes verstuurt. 2x parity en 4x data. De originele informatie van de chunk is niet nodig omdat precies een hele chunk wordt overschreven. Dus geen reads, alleen writes.

Het kan zijn dat de Linux Kernel hier smokelt omdat je voor de nieuwe XOR parity informatie natuurlijk niet de hele chunk nodig hebt. Als je maar een halve chunk volschrijft met data dan kan dat ook voor de parity. De chunk-size is dus eigenlijk een logische eenheid in de kernel om informatie naar de schijf te schrijven/lezen.

Voor raid 0 of 1 is het dus praktisch gelijk aan je read/write window waarbij een groter window gelijk staat aan minder I/O ops en dus minder overhead. Goed voor sequentielle reads/writes maar slechter voor random reads/writes waar juist een kleiner window maar meer I/O ops beter prestaties biedt. Voor Raid4, 5 en 6 beinvloedt het daarnaast dus ook hoe de parity wordt ge-update en dat kan zo 30% prestatie verschil maken.

Voor Ext 2 en 3 is block-size mischien de verkeerde naam en zou het eigenlijk stride-size moeten heten.

Kortom: de totale grote van je data-chunks moeten precies gelijk zijn aan de block-size van je filesystem voor optimale prestaties. De chunk-size is immers de kleinste grote die geschreven kan worden en alle writes zouden precies hele chunks moeten omvatten. Je block-size mag dus wel een meervoud zijn van je chunk-size maar nooit kleiner of afwijkend zijn van je chunk-size om read-modify-write cycles te verkomen.

Maar om eerlijk te zijn is waarschijnlijk zelfs een slecht geoptimalizeerde raid 5 of 6 array al genoeg om je gigabit netwerk vol te trekken. Een enkele schijf vandaag de dag zit al behoorlijk richting die theoretische 128MB/s.

[Demo]

Docey: ik heb het een en ander zitten lezen en je hebt inderdaad gelijk. Echter zal er vooral gelezen worden van deze array en ik kwam de tip tegen om het FS te mounten met 'noatime', zodat er bij leesactiviteit ook geen access times geschreven gaan worden. Stride is overigens ook een optie bij het bakken van een ext3 filesystem, waarbij je de stripe size van je array moet delen door de block size die je voor je FS gebruikt. Daarbij kan je ook nog stripe-width oid gebruiken, waarmee je aangeeft hoeveel (data)schijven je hebt. Volgens de mke2fs manpage: "This allows the block allocator to prevent read-modify-write of the parity in a RAID stripe if possible when the data is written."
En een slecht geoptimaliseerde array trekt inderdaad ook een gbit-connectie wel vol, maar het is toch leuk om het op elkaar af te stemmen En omdat er vooral gelezen zal worden, denk ik dat ik beter daarop kan optimaliseren (het voordeel van grotere blocks en chunks heb ik ooit met m'n Areca getest en heeft zeker invloed op sequentiële reads) dan op writes. Desnoods ga ik m'n manier van werken aanpassen (downloads op m'n OS-schijf binnenhalen ipv op de array) om er voor te zorgen dat er minder random writes gedaan worden.

Voor anderen die dit topic ooit nog lezen trouwens nog een aanvulling op de 'man mdadm' tip: man 4 md. Aangezien de mdadm pagina vooral uitleg geeft over alle commando's, de pagina van md gaat veel dieper in op de opbouw van een array.

[Verwijderd]

Demoniac schreef op vrijdag 17 april 2009 @ 13:40:
Docey: ik heb het een en ander zitten lezen en je hebt inderdaad gelijk. Echter zal er vooral gelezen worden van deze array en ik kwam de tip tegen om het FS te mounten met 'noatime', zodat er bij leesactiviteit ook geen access times geschreven gaan worden.

relatime ipv noatime volgens goed gebruik tegenwoordig

En een linkje waarom: http://kerneltrap.org/node/14148

[ Voor 6% gewijzigd door Verwijderd op 17-04-2009 19:24 ]