On Wed, 7 Jan 2009, Dmitry Koterov wrote:
> The question is: will physical writes be performed later in the sequence of
> physical SECTOR position on the disc (minimizing head seeking)? Or Linux
> background writer knows nothing about physical on-disc placement and flushes
> data in order it is saved in the RAM?
The part of Linux that does this is called the elevator algorithm, and
even the simplest I/O scheduler (the no-op one) does a merge+sort to
schedule physical writes. The classic intro paper on this subject is
http://www.linuxinsight.com/files/ols2004/pratt-reprint.pdf
> What I am trying to understand - why does the system fall to a writing
> bottleneck (e.g. 10MB/s) much before it achieves the maximum disk
> throughput (e.g. 50MB/s). How could it happen if the Linux IO scheduler
> reorders write operations, so time for seeking is minimal?
I think you're underestimating how much impact even a minimal amount of
seeking has. If the disk head has to move at all beyond a single track
seek, you won't get anywhere close to the rated sequential speed on the
drive even if elevator sorting is helping out. And the minute a
checkpoint is involved, with its requisite fsync at the end, all the
blocks related to that are going to be forced out of the write cache
without any chance for merge+sort to lower the average disk I/O--unless
you spread that checkpoint write over a long period so pdflush can trickle
to blocks out to disk.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD