russki :
No, not irrelevant. Just maybe a bit over the head. For example, the points that you make are really good, but maybe you could expand on the reasons why. We really need more well informed posters like you around here. But it is also true that we can learn more from understanding the reasons and not just the consequences.
Okay, i'll try to explain it a bit. Storage can be pretty complicated though, surprisingly, many reviewsites make huge mistakes. That's why i decided to write articles about storage, but i have not finished them yet.
Stripe misalignment
In a striping RAID scheme the data is stored non-contigious on the disks. This means that to read 1MB you cannot read all that from a single disk in a RAID0 configuration. You can with RAID1, because that scheme uses no striping. RAID1 is unaffected by stripe misalignments.
So what is a misalignment? Well, your filesystem (FAT/NTFS/EXT3/UFS) has to begin somewhere. You would think it starts at the beginning of the volume (a single disk or RAID volume), but it doesn't. It leaves space in front of the partition to store the DOS partition table ("fdisk") and to store the master boot sector for BIOS boot support. Each sector is 512 bytes large. Normally the first partition starts at an 'offset' of 63 sectors. Let's see this visually:
[fixed]| 63 sectors for partition table | 40GB NTFS partition | 20GB other partition |[/fixed]
In a single disk configuration this is no problem at all, however in a striping (RAID0/3/4/5/6) configuration there are performance difficulties. If your stripesize is 64KB and you want to read 64KB then ideally this means you have to access just one disk. A subsequent 64KB request can be processed by another disk member, this is the parallellism effect RAID0 gains its performance from. If there is a misalignment between stripe blocks and the filesystem offset, then a file on the filesystem will nog start on the beginning of a stripeblock. Meaning: a file will not start at offset 0KB of a 64KB stripeblock but at 31.5KB for example. If you then read 64KB, you have to read from 2 disks instead of 1!
[fixed]
| 64KB stripe on disk1 | 64KB stripe on disk2 | 64KB stripe op disk3 |
| unused | 64KB FILE ON FILESYSTEM | ~~another 64KB block~~ | [/fixed]
As you can see, the blocks on the filesystem do not start at the same point as a stripe block. This is called a misalignment. To read the first 64KB block, you need to read both from disk1 and disk2. That means both disks are busy with 1 request and that both are not available for other I/O requests. Ideally you want one I/O request to be handeled by 1 disk, so that the other disks are able to process other requests. With a stripe misalignment this effect is hindered and sometimes effectively negated. A solution is to use a 1MB offset for your filesystem, something Microsoft should have done if they had any clue:
[fixed]
| 64KB stripe on disk1 | 64KB stripe on disk2 | 64KB stripe op disk3 |
| ~~~~unused space~~~~ | 64KB FILE ON FILESYS | ~another 64KB block~ | [/fixed]
Here you have a 64KB offset at the beginning of the filesystem; now they are perfectly aligned! However you still have a misalignment if you use a stripesize of 128KB or higher. So probably an offset of 1MB should be used. Then it would consume 8x 128KB stripes or 16x 64KB stripes as 'unused' (though they hold the boot code and partition table). Another solution is to use Dangerously Dedicated mode, in which there are no partitions. Then the filesystem starts at offset 0. Windows does not support this mode to my knowledge.