Thanks for pointing that out, i didn't know Vista finally corrected this easily avoidable misalignment. I'm puzzled by your 'more often aligned' though. If it aligns on exactly 1024KiB offset it should always be properly aligned, with any stripesize up to 1MiB. Can you clarify?
Anyway, that still means anything below Vista by default has the worst possible misalignment on any RAID - software or hardware. Windows also does not allow 'Dangerously Dedicated' mode, in which no partitions are used at all. Also, many people don't know about this misalignment problem and how to correct it. They end up having a volume that may be fast on sequential transfers (due to buffering and non-contiguous access, the misalignment doesn't do much harm). But their IOps are crippled, especially RAID5 random write ends up far worse than necessary. And IOps are still the most important for both desktop and server systems.
What exactly don't you agree on? A 1MiB offset should provide perfect alignment for stripesizes up to 1MiB, no matter what RAID level you use. RAID1 is exempt because it has no stripes and thus no misalignment.
As for stripesize, as you said ideally you want one virtual I/O to be processed by one physical hard drive. A too low stripesize (and a misalignment) could mean multiple disks are working on one virtual I/O request. Some believed this to increase sequential throughput, but its far better to have a large stripesize so all random reads and writes can be handled by one physical hard drive, and the other disks in the RAID can be occupied for other I/O requests. This only works if there are multiple I/O requests, so some applications using "blocking I/O" read requests won't see the full potential of the RAID volume. This is often noted in HDTune, which only used a queue-depth of 1 to access the device, bypassing all the optimizations the filesystem does. By using ATTO to benchmark your RAID you see what you would truely be getting when operating on the filesystem level. This is because the filesystem uses buffering, write-back and read-ahead mechanisms, which send multiple I/O requests at once. I expect you to know this, but i hope its an interesting read also for others.
I understand what you mean, but i think this is wrong. Why should the full stripe block (or chunksize as you call it) be aligned? Normally only the stripe cells should be aligned, as in:
| DISK 1 | DISK 2 | DISK 3 | DISK 4 | Physical disks
| 64K | 64K | 64K | 64K | Stripeblock (RAID-level)
| 32K | 32K | 32K | 32K | 32K | 32K | 32K | 32K | Filesystem block (what you set during partitioning and formatting)
| RRRRRRRRRRRRRRRRRR | ........................ | R=Read request (71KiB)
As you can see, all filesystem blocks fit into the stripeblock and are perfectly aligned. Now that i'm thinking about it, i think you're referring to the RAID5 write hole. In my example of 71KiB read, there is no problem and no misalignment. But when writing sequentially, some dumb drivers don't buffer the requests. So in fact all I/O has to be done in 2 phases - first read parity, calculate new parity, write parity+data. Besides this being extremely slow it also wears your disks because they will have to seek excessively. But intelligent RAID5 drivers will buffer the writes and always write full stripe blocks (192KiB in this example when using RAID5). Once writes come in from the operating system, it will be stored and if within x seconds a full stripe block is detected it will be written out with full efficiency and speed. That's why the geom_raid5 driver in FreeBSD/FreeNAS manages to achieve 400MB/s write performance in 8-disk RAID5 (disks do 70MB/s). Beating my Areca ARC-1220 by the way, which is still faster for any random IOps task.
For some dumb drivers like nForce MediaShield RAID5, it is possible to see high performance to manually correct for the RAID5 write hole, which is i think what you meant. But why should people trust a dumb implementation for their data? If you use Windows, just buy a good controller and a BBU, then you'll be fine. If you use Linux or BSD you can save yourself the cost for such an investment, because the software is smarter. I ofcourse like the last approach, but i understand people want to stick with Windows.
Ah he has three drives, sorry i overlooked that
This is odd then, but i don't know his controller. Maybe he can try to tweak it, my Areca has several options in the BIOS menu, like write-back, read-ahead, NCQ, etc. or he can use the onboard controller for his raptors in RAID0 which should also be very fast. Just don't use them in RAID5.
BTW, nice to see some well informed users related to storage, i was beginning to think they were extinct.