Aligneren van partities op Areca RAID

[Rygir]

Zonet heb ik een beetje gelezen over dat nieuwe HDs dus willen overstappen op sectoren van 4k. Daar stond bij vermeld dat partities dus verkeerd kunnen gealigneerd zijn dankzij windows XP.

Nu heb ik de link gelegd naar de 2TB+ compatibiliteitsoptie van 4k sectoren die Areca Raid controllers bieden, en die ik ook gebruik...zonder dat ik had gedacht aan die aligneringsproblemen. Wil dat nu echt zeggen dat het kan zijn dat mijn sectoren verkeerd gealigneerd zijn? Hoe kan ik dat nakijken? De performance lijkt in orde, maar ik zou het graag "zeker" weten... de methoden die ze in het artikel aandragen, namelijk Western Digital software lijken me vrij risicovol om los te laten op een raid array, als ze al iets doen.

Dus (1) zijn logische volumes gebaseerd op 4k sectoren altijd kwetsbaar voor dat aligneringsprobleem?
(2) als dat zo is, houdt de raid controller er zelf al rekening mee of zo?
(3) hoe stel ik vast of mijn alignering mis zit?
(4) Opties voor het te corrigeren?

[PipoDeClown]

Misschien is enige wat antwoorden geeft op de vragen om er een aantal tests op uit te voeren.

Voorheen alignde men de partities op een veelvoud van 32 of 64 sectoren (512 bytes / sector), nu is het advies 1024. Ik weet niet of dat ook geldt bij sectoren van 4K.

Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000

[Rygir]

Hmmm, in dat artikel van MS kb dat je linkt staat dat ze diskpart gebruiken... maar ik heb nu eigenlijk gewerkt met logische volumes van de Areca controller zelf, die ik dan integraal formatteer...

De stripe size is trouwens 64k die ik gebruik... als ik 4k sectoren heb zijn dat er dus 16 samen, maar ergens leek het mij altijd logisch om stripe size==sector grootte te nemen, maar dat is niet eens een optie voor <4k sectoren meen ik? Grotere stripe sizes geven ook meer snelheidsboost naar het schijnt voor grotere bestanden, wat ik dan weer vreemd vind... hij moet de sectoren tenslotte toch bij mekaar gaan zoeken?

En erger nog, de clusters die het file system gebruikt zijn toch ook 4 k? Maar dat is misschien als het niet gefragmenteerd is geen ramp?

In ieder geval, ik wil liever het risico vermijden van hele partities met gegevens op te gaan schuiven, als dat mis gaat kom ik in de problemen. Zoiets had ik liever op een leeg array getest, of een blanco PC, en dat heb ik niet beschikbaar...dus zomaar in wilde weg gaan esten is niet echt een optie...Op dit moment toch niet.