Advies gevraagd voor RAID instellingen 2420SA

[olie]

Ik vroeg me hoe ik het beste mijn instellingen kan configureren voor de volgende opzet:

Adaptec 2420SA (dedicated controller) 128MB read/write cache
4x Seagate 7200.11
Windows XP64

Voor nu heb ik:
1x RAID 0 array 64kB stripesize, grootte 100GB gemaakt voor windows op schijven 0 en 1
1x RAID 0 array 256kB stripesize, grootte 100GB gemaakt voor gameinstallaties op schijven 2 en 3
1x RAID 5 array 256kB stripesize, voor de rest van de schijfruimte voor dataopslag. schijven 0,1,2 en 3

Clustersize voor windowspartitie 4kB, voor gameinstallatiepartitie 32kB, en voor dataopslag 32kB

Weet iemand hoe het beter kan?
Ik vraag me af of clustersize net zo groot moet als de stripesize?

[Femme]

Adaptec raid-controllers presteren meestal het beste met een stripe-size van 256K.

[olie]

Femme schreef op donderdag 17 januari 2008 @ 16:12:
Adaptec raid-controllers presteren meestal het beste met een stripe-size van 256K.

Maar voor de windows partitie kan ik toch geen 256kB stripesize gebruiken?
Veel bestanden zijn klein zodat er veel slackspace ontstaat...(of heb ik het nu helemaal mis?)

Moet de clustersize nu wel of niet gelijk zijn met de stripesize?

[olie]

Kan niemand verder wat zinnigs zeggen?

[Verwijderd]

Slack heb je niet bij een bepaalde stripesize. Je bedoelt denk ik clustersize (of block size) van je filesystem, doorgaans iets als 8 of 16KiB. Daarvoor geldt inderdaad dat gemiddeld de helft per file aan slack verloren gaat en dus onbruikbaar is. Bij striping heb je dat probleem niet. Je kunt in principe prima stripesizes van 20MB of nog groter gebruiken. Stripesize >= 128KiB valt aan te raden, clustersize niet te hoog als je veel kleine files erop gaat zetten.

[ Voor 61% gewijzigd door Verwijderd op 19-01-2008 23:00 ]

[jwpmzijl]

@Olie
Slack heb je in combinatie van met clustersize en dat hangt weer samen met het filesysteem dat het OS gebruikt.
De stripesize bij RAID controllers bepaalt echter de grote van de datablokken die de controller per keer leest cq. schrijfhandeling naar of van de RAID transporteerd.
Deze stripesize kun je met huidige hardeschijven en controllers over het algemeen het beste zo hoog mogelijk instellen.

[ Voor 0% gewijzigd door jwpmzijl op 20-01-2008 02:19 . Reden: typo ]

[olie]

OK, nu snap ik het;
De stripesize geeft aan hoeveel bytes er in een stripe worden weggeschreven.
Maar stel we hebben een clustersize van 8kB en een stripe van 64kB, er moet 22kB worden weggeschreven dus 3 clusters, wat word er dan gedaan met de overige 5 clusters?
Is dit dan slack space of word er gewacht met schrijven tot er 8 clusters zijn om te schrijven?
Of word er een gedeelte van de stripe geschreven en de rest later?

Nu heb ik 4 schijven van 500GB waarbij 200GB RAID 0 en de rest RAID 5.
Bij het installeren van Windows XP64 doe ik altijd een format op de partitie.
Wil het nu zijn dat die eigenwijze Windows alleen 4kB clustersize (snel)formateert.
Kan ik de clustersize naar 16kB brengen zonder weer opnieuw windows te hoeven installeren?
Zou het OS daar sneller van worden?
Ik heb nu een quad core@2.2GHz, een 64bit/133MHz (1GB/s) Sata RAID controller en 4 snelle schijven. Toch moet ik nog vaak wachten op de datastromen, hoe kan dat nou???

Oh ja, mijn controller heeft op zijn hoogst 1024kB (1MB) stripesize. Een 20MB stripesize zoals Enlightenment zegt is wel heel erg veel, bedoeld ze soms 2MB of is mijn controller al weer obsolete?

[ Voor 46% gewijzigd door olie op 27-01-2008 04:56 ]

[Verwijderd]

Ik bedoelde 20MB.

Punt is: je stripesize kan eigenlijk niet te groot zijn, wel te klein. Je wilt dat één I/O request door één schijf afgehandeld wordt. Een I/O request in Windows XP is maximaal 64KiB groot en bij vista ongelimiteerd, als ik het goed herinner. Meerdere schijven gebruiken voor één request is dus onzin omdat de seektimes een groot deel van de latency uitmaakt, die 64KiB is door moderne 7200rpm schijven supersnel gelezen. Het probleem bij hardeschijven is dat ze moeten seeken en dat relatief gezien reusachtig veel tijd kost. Zelfs 0.1 milliseconde betekent al 30.000 instructies op een 2GHz processor.

Sommige (veelal onboard) controllers of software implementaties hebben wel een belangrijke beperking: ze vragen álle data op in een stripeblock opvragen, ook al is maar om 2KiB gevraagd. Dit wordt denk ik gedaan om op een goedkope manier de doorvoer te verbeteren, in feite dus een vorm van read-ahead. Bij dit soort controllers kan een hoge stripesize voor performance problemen zorgen voor alles behalve sequentiële doorvoer, en kun je het beste maar 64KiB kiezen.

Mijn Areca gaat ook maar tot 128KiB, kies dan gewoon het grootste wat je kunt kiezen. Ik had wel graag getest hoe de Areca het zou doen met veel grotere stripesizes...

olie schreef op zondag 27 januari 2008 @ 04:37:
De stripesize geeft aan hoeveel bytes er in een stripe worden weggeschreven.
Maar stel we hebben een clustersize van 8kB en een stripe van 64kB, er moet 22kB worden weggeschreven dus 3 clusters, wat word er dan gedaan met de overige 5 clusters?
Is dit dan slack space of word er gewacht met schrijven tot er 8 clusters zijn om te schrijven?

Er zijn geen "overige 5 clusters" je filesystem ziet de array als één lange reeks sectoren waar het naar toe kan schrijven. Conclusie: stripesize heeft geen invloed op de hoeveelheid slack.

Het enige wat wel een minimale invloed heeft is de sector size, die geeft de ondergrens aan voor onverdeelbare data. Het filesystem mag niet een gedeelte binnen de sector opvragen. Ook als het filesystem maar 14 bytes wilt schrijven, moet het alsnog 512 bytes aan data versturen. De stripesize is vrijwel altijd 512 bytes maar er zijn uitzonderingen (FreeBSD: GELI encryptie, Vinum volume manager, geom_raid3). In de praktijk valt alle slack dus aan je filesystem te wijten, en in het geval van NTFS is dat de cluster size. Formule:

(clustersize / 2) * aantal files = totaal aantal slack

Met andere woorden: voor elke file ben je de helft van de clustersize kwijt aan slack.

[Femme]

Dat is een mooie uitleg.

Je leest wel eens opmerkingen van mensen die het advies geven om de stripesize zo klein mogelijk te maken zodat er zoveel mogelijk harde schijven tegelijkertijd aan het werk gezet worden. Zoals Enlightenment uitlegt is dit niet gewenst, omdat de toegangstijd van de harde schijven voor non-sequentiële I/O een zeer groot aandeel heeft in de totale responstijd van een I/O. Bij ssd's is dit wellicht anders maar bij harde schijven heb je het liefst een zo groot mogelijke stripesize. Meestal is 128K of 256K het snelst, daarboven wil de situatie nog wel eens omkeren. Een zeer kleine stripesize van bijv. 8K of 16K levert zelden een positief resultaat.

Hier is meer info op het Adaptec Storage Advisors blog.