Hát, tudomásom szerint NTFS alatt 64k a max cluster méret. A stripe méret a raid vezérlő függvénye, ma már mindegyik tud 1024-et, valóban.
Nem állítottam, hogy a stripe=cluster/drive szám lenne a jó megoldás. Azt állítom, hogy a cluster>stripe size nem jó megoldás. Viszont mivel a cluster max 64k, ezért 64k stripe felett ugye esélytelen egyenlőre állítani, tehát mindenképp kevesebb lesz 
Igen, az említett esetben 2 vinyórol jön az adat. A baj, hogy onnan jön mindenképp. A vezérlőnek esélyt sem adunk, hogy párhuzamosítson IO műveleteket, mivel gyakorlatilag a 2 diszk szinkronban mozgatja a fejet, ilyenformán korlátozod a max IO/sec számot. Ez nyilván nem 1 szálú szekvenciális olvasáskor gond, de kisebb méretű, nem szekvenciális mintázatkor már gondot fog okozni. Ha valaki arra gyúr, hogy x tesztprogramban közel 2szeres eredményt lásson szekvenciális műveleteknél, akkor ez jó beállítás lehet. A valós alkalmazáskor viszont alig fog gyorsulni a tömb.
Az utolsó pontra annyit, a cluster max 64 lehet. Ha a stripe kisebb, akkor a fenti eset van. Ha egyenlő, az az, amit jónak tartok. Ha nagyobb, az szintén egy jó eset.
Pl. 1024k a stripe, 64k a cluster. Itt a 2MB nál nagyobb méretű file-ok olvasásánál ideális esetben 2-szeres sebességet kapunk. Az 1024 alattiaknál viszont legrosszabb esetben 1 diszk sebessége mérhető.x
A raid tömb nagy előnye azon túl, hogy nagy MB/sec- eket lehet kihozni belőle az, hogy egész jó skálázódóan növeli az alrendszer IOPS értékét.
Még egy apróság a cluster méret az a méret, ami a legkisebb egység lesz NTFS fileműveletek esetén, de nem a maximum. Azaz, 4kb cluster méret esetén normális, a 64kb blokkokban való olvasás. Ez annyit jelent, hogy a cluster méretet nem csak a stripe mérettel kell a megfelelő viszonyban tartani, hanem a jellemző írási/olvasási blokkmérettel.
Ízirájder öcsém, ízirájder...
