File system blocks alignment

[James R. Van Artsdalen]

Scott Long wrote:
> It's all about read latency in the read-modify update operation.

In this case it's about rotational latency - read/modify/write
necessarily adds a full rotation onto the I/O time, above and beyond the
read latency.  At 5400 rpm that's 11 ms added.

To an extent this can be masked by deferring the write and doing other
I/O until the disk rotates to a favorable position (a short seek is
faster than a rotation).  But the cache is only so big and the drive may
have to take the hit and do the writes even at an unfavorable point if
something like newfs saturates the cache.

I am surprised the hit is so bad.  I guess we'd have to look at a
trace-tape of the I/O but I would have expected many of the writes
(after r/m/w) from newfs and restore to be combined in each cg, and many
reads eliminated due to data already being cached via speculative reads
(while waiting for the disk to rotate for a write the drive might as
well read what's passing under the head and cache it).

(of course, the bad hit may just be the result of v1.0 firmware, or
on-drive processors that turned out to be too slow for efficient r/m/w
algorithms under real-world loads)

Faster rotation rates win, but the bit-density goes down at higher
speeds.  So a 15k SAS drive may be faster than a 7200 rpm but it's
nowhere near twice as fast.