Re: File system blocks alignment
- From: "James R. Van Artsdalen" <james-freebsd-current@xxxxxxx>
- Date: Fri, 01 Jan 2010 19:53:36 -0600
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.
freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: File system blocks alignment
- Next by Date: Re: File system blocks alignment
- Previous by thread: Re: File system blocks alignment
- Next by thread: Re: File system blocks alignment