No, the RAID controller does not save things in increments. The RAID controller has nothing to do with file allocation, that is a function of the file system and it's allocation size.
You are thinking of allocation size (also called cluster size), which is a file system parameter. Higher allocation sizes result in wasted space because files smaller than the allocation unit use an entire allocation unit regardless. For example, in the old FAT and FAT32 file systems, allocation unit size was sometimes set high in order to accomodate large disks, like 32K for example. Then, any file smaller than 32K still uses 32K of disk space.
This wasted space (sometimes called cluster waste or cluster slack) is generally not a problem anymore with NTFS. First, the default allocation unit size with NTFS is 4K, even for extremely large disks. Second, files smaller than about 768 bytes can be stored directly in NTFS's MFT structure on the disk, and therefore use no clusters at all.
But the stripe size is a parameter of the RAID controller at the block level, and has nothing to do with files. It only describes the grouping of blocks into the stripes which will be simultaneously read by the controller. The issue here is that files smaller than the stripe size will not receive the benefit of the simultaneous reads - more blocks of their data will be on one drive than the other. Files smaller than (stripe size)/n (where n=number of drives in the RAID 0) will generally reside only on one drive, and won't get any read speed benefit. But in no case are any sectors on the drive wasted at the RAID controller level. When the NTFS file system goes to allocate clusters for another file, the RAID controller will stack those directly behind the last sectors, regardless of the stripe size.
Facebook
Twitter
Instagram