![](https://seccdn.libravatar.org/avatar/25bbc96d9c53647354cb724e744b2222.jpg?s=120&d=mm&r=g)
Felix, You asked about the subject, but your thread went on in other directions. The performance penalty varies based on access pattern. For reads, there is basically no penalty. A modern rotating disk reads an entire track at a time and puts it in the drives internal cache. A modern track is roughly 1MB, so when you see a disk drive with a 8MB cache, that means it can hold 8 tracks. It does NOT mean it will hold 8MB of random i/o data scattered around the disk. It is far better to think about that cache as 8 track buffers. So if you issue a unaligned page read, the drive will read in the entire track the page resides on and then will transfer that to the kernel. No meaningful penalty at all if the unaligned page resides on a single track. If the unaligned page resides on 2 tracks due to the misalignment it will trigger 2 track reads and possibly a disk seek at the internal drive level. If the 2 tracks are on the same cylinder, a disk seek is still not needed, so the penalty is another rotation of the disk. If the 2 tracks are on different cylinders, then a disk seek between 2 contiguous cylinders is needed, but that is also pretty quick (a couple msecs I think with modern drives). If a track is 1MB, then there are 250 4KB pages / track, so only one time in 250 do you have a performance penalty. (Drives have variable pages / track based on the diameter of the specific track. Tracks near the center of the drive have a much small diameter than a track on the outer edge, so the likelihood of incurring the penalty is about twice as high at the "end" of the disk. The trouble is with writes. For long sequential writes, there is minimal penalty again because the misalignment only happens at the start and end of the transfer. ie. dd bs=1MB will trigger 1 MB i/o's to the drive and only the first and last page get hit with a performance penalty. If the workload is small 1 page writes, then the penalty is huge. For every write a read/modify/write cycle has to be implemented. At the drive level that means every write requires an entire disk rotation to implement the read. The modify is free, but then a second rotation is needed to do the write. A 7200 RPM drive takes roughly 8.3 milliseconds to make a rotation, so every 1 page unaligned write takes an extra 8.3 milliseconds to complete. You would need to benchmark your typical load, but if you do lots of small i/o's, I think you will find that 8.3 msecs a pretty major penalty. == specific to 1 KB pages == Alignment won't help much in the general case. If you write a 1KB random i/o to a 4KB page, the drive is still forced to do: read track, modify data, write track. If the 1KB page is unaligned, it is the same except in the rare case that the 1 KB is split over 2 tracks where it becomes: read track1, modify data, write track1 seek disk if needed read track2, modify data, write track2 But a 1KB page being split between 2 tracks should happen much less than 1% of the time. If you are going to use drives with 4KB physical sectors you need to avoid filesystems with 1KB blocks. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org