Greg Smith wrote:
> If you write a giant block of writes, those tend to be sorted by the
> OS and possibly the controller to reduce total seeks. That's a pretty
> efficient write and it can clear relatively fast.
>
> But if you're been trickling writes in an unstructured form and in low
> volume, there can be a stack of them that aren't sorted well blocking
> the queue from clearing. With a series of small writes, it's not that
> difficult to end up in a situation where a controller cache is filled
> with writes containing a larger seek component than you'd have gotten
> had you written in larger blocks that took advantage of more OS-level
> elevator sorting. There's actually a pending patch to try and improve
> this situation in regards to checkpoint writes in the queue.
>
> Seeks are so slow compared to more sequential writes that you really
> can end up in the counterintuitive situation that you finish faster by
> avoiding early writes, even in cases when the disk is the bottleneck.
I'm sorry but I am somewhat unconvinced by this.
I accept that by early submission the disk subsystem may end up doing
more seeks and more writes in total, but when the dam breaks at the
start of the checkpoint, how can it help to have _more_ data write
volume and _more_ implied seeks offered up at that point?
Are you suggesting that the disk subsystem has already decided on its
strategy for a set of seeks and writes and will not insert new
instructions into an existing elevator plan until it is completed and it
looks at the new requests? This sounds a bit tenuous at best - almost to
the point of being a bug. Do you believe this is universal?
James