NTFS RAID 0 stripsize en clustersize debacle

[Pesticide]

wreed intrigerend als ge t zelf hebt mor wreed irriterend als ge nergens deftig reviews en benchmarks vindt

mensen hier met ervaring ?

Ik heb zelf aan den lijve ondervonden dat met een stripesize van 16kb en default ntfs clustersize (512b i assume) mijn performance terrible was in benches zoals sisoft en hdtach 2.61

nu geformat met clustersize 16k en voila mijn performance is weer wat t moet zijn

nu hebbik schrik voor fragmentatie omwille van die grote clustersize (NT gaat namelijk later deze waiste of space terug opvullen het geen fragmentatie veroorzaakt) maar als ik nu bijvoorbeeld stripezise 512bytes zou pakken en bijhorende clustersize dan zou dit rampzalig worden voor divx filmpjes of eender ander groot bestand te kopieren aangezien hij deze bestanden in duizenden kleinde bestandjes met delen om t weg te schrijven

ook graag info omtrent partities en ntfs 8gig of groter is best om fat32 te evenaren qua performance en zelf te overstijgen ?

desnoods ga ik overschakelen op slecht 1 partite van 90 gig nimeer als dat de performance ten goede komt (kzie mij namelijk niet rap meer formatten met dien sweet nieven kernel)

iemand die hier meer ervaring mee heeft of zijn ervaringen hiermee zou willen delen of goede urls weet omtrent dit porbleem ?

kzeg u wel nooit mee win98 als leecher , gamer en iemand die pc nodig heeft voor pro stuff : leecher : crash = grote kans op dataloss , gamer : crashes , pro crashes

winXP troubles waren hier dus t ntfs raid probleem dat nu opgelost geraakt engforce kaart die plots een refresgrate minder aankan mor word opgelost door superiere ati te gaan halen chez padeg met 400 mhr ramdac tgeen hopelijk een openbaring gaat worden op mijn 22 inch

[Varienaja]

Wazeggie?

[Freez]

Op dinsdag 22 januari 2002 18:11 schreef Varienaja het volgende:
Wazeggie?

ik wilde het niet zeggen maar je legt de woorden in m'n mond

maar wat is het probleem nu eigenlijk?

[Pesticide]

"nu hebbik schrik voor fragmentatie omwille van die grote clustersize (NT gaat namelijk later deze waiste of space terug opvullen het geen fragmentatie veroorzaakt) maar als ik nu bijvoorbeeld stripezise 512bytes zou pakken en bijhorende clustersize dan zou dit rampzalig worden voor divx filmpjes of eender ander groot bestand te kopieren aangezien hij deze bestanden in duizenden kleinde bestandjes met delen om t weg te schrijven
"

ik zou dus over wille schakelen naar 512 stripesize omzo de default clustersize van NTFS op respectable benchmark scores te gebruiken maar heb dus schrik voor large file transfers die dan zeeer traag zullen gaan en zou graag bevestiging of tegenbevinbdingen willen hebben van mijn vermoedens

[Access]

Oke, hier hoe het volgens mij zit:

cluster size = groot == veel slack, hoge doorvoersnelheid
cluster size = klein == winig slack, lagere doorvoersnelheid

[Freez]

Op dinsdag 22 januari 2002 18:20 schreef Pesticide het volgende:
"nu hebbik schrik voor fragmentatie omwille van die grote clustersize (NT gaat namelijk later deze waiste of space terug opvullen het geen fragmentatie veroorzaakt) maar als ik nu bijvoorbeeld stripezise 512bytes zou pakken en bijhorende clustersize dan zou dit rampzalig worden voor divx filmpjes of eender ander groot bestand te kopieren aangezien hij deze bestanden in duizenden kleinde bestandjes met delen om t weg te schrijven
"

ik zou dus over wille schakelen naar 512 stripesize omzo de default clustersize van NTFS op respectable benchmark scores te gebruiken maar heb dus schrik voor large file transfers die dan zeeer traag zullen gaan en zou graag bevestiging of tegenbevinbdingen willen hebben van mijn vermoedens

de default cluster size van NTFS is 4kb, dit is wel ongeveer qua scores het gemiddelde tussen 512 b en 16 k, het is nu dus snel met kleine en grote bestanden.

hopelijk heb ik de "vraag" goed begrepen, moest hem wel erg vaak over lezen

[Pesticide]

het clustersize principe hebbik wel door ondertussen maar nu komt de moeilijkheid van een raid 0 STRIPEsize hier nog eens bij kijken ;-)

die bepaald mede hoe je benchmarks zullen zijn en hier had ik liefts opmerkingen gehad van mensen die zelf een ntfs raid 0 hebben bollen

aangezien de stripesize de waarde is op welk punt de controller da bestandjes moet verdelen om ze zo via beide HD's tegelijk te schrijven

en 700 MB divxje gedeeld door 512 bytes = onnoemlijk veel deeltjes dat ie zal moeten wegschrijven for example

[Anoniem: 898]

Gewoon niet teveel rotzooien met die clustersize. Je kunt ermee blijven experimenteren tot je een ons weegt. In plaats daarvan is het (weliswaar een stuk duurder maar) veel zinniger om een raid controller aan te schaffen met een flinke berg cache. Lost al je (veronderstelde) latency problemen op.

De reden waarom je niets over die clusters op Internet vindt is simpelweg omdat het in de praktijk niet erg loont om ermee te gaan experimenteren. Er zijn zo enorm veel parameters die bepalen wat de meest gunstige cluster size is dat je er in de praktijk vaak niet zoveel mee op schiet om de default aan te passen.

[Pesticide]

de stripe / cluster combi is nogtans zeer benchmark gevoelig , zo had ik dus 16 k stripesiez en default nttfs cluster size = > 19.000 sisoft score en hdtach om in zwijm van te vallen


format ik ze nor 16k cluster = > 42 sisoft enhdtach +- zoals in win98 met fat32

mij is t dus gewoon te doen om zulke troubles te vermijden als ik nog eens voor laaste maal alles format en nieuwe raid array aanmaak dat ie de +- beste is die er is zodat ik niet weer eens opniuew moet beginnen

doel : speeed ; defragmentatie voorkomen en niet teveel ruimte verliezen alhoewel dat op me 2*80 raid 0 van minder belang word (ga dus 2 maxtors 80 gig aanschaffe)

[Anoniem: 898]

De configuratie is inderdaad nogal benchmark gevoelig, maar vergeet niet dat een benchmark een benchmark is en niet noodzakelijkerwijs iets over de daadwerkelijke prestaties van je machine / configuratie in real life zegt.

Wat ik hiermee bedoel is dit: als de benchmark bijvoorbeeld de snelheid van schrijven / lezen test door pakketjes van 2048 byte weg te schrijven en je hebt ook een zelfde clustersize, dan zal de benchmark zeker een positief resultaat aangeven. Als je echter in de praktijk vooral pakketjes van gemiddeld (ik noem maar wat) 300kB gaat wegschrijven dan heb je zeker geen optimale clustersize voor optimale performance.

Wat je dus eigenlijk zou moeten weten is wat de gemiddelde grootte is van de files die je in de praktijk bewaart / wegschrijft. En kom daar nu maar eens achter.

Een ander alternatief is - als je toch perse je clustergrootte aan wil passen - om een benchmark te gebruiken die verschillende grootten van pakketjes wegschrijft. Mogelijk dat je uit die resultaten (als je ze ordent op grootte van het pakketje) een optimale clustergrootte kan bepalen.

Maar het blijft volgens mij hoe dan ook "natte vinger" werk. En zoals gezegd kan een flinke cache het resultaat zwaar beïnvloeden.