> On Tue, Jun 15, 2010 at 04:36:43PM +1000, Dave Chinner (
david@fromorbit.com) wrote:
> > > Nope. Large-number-of-small-files is a pretty common case. If the fs
> > > doesn't handle that well (ie: by placing them nearby on disk), it's
> > > borked.
> >
> > Filesystems already handle this case just fine as we see it from
> > writeback all the time. Untarring a kernel is a good example of
> > this...
> >
> > I suggested sorting all the IO to be issued into per-mapping page
> > groups because:
> > a) makes IO issued from reclaim look almost exactly the same
> > to the filesytem as if writeback is pushing out the IO.
> > b) it looks to be a trivial addition to the new code.
> >
> > To me that's a no-brainer.
>
> That doesn't coverup large-number-of-small-files pattern, since
> untarring subsequently means creating something new, which FS can
> optimize. Much more interesting case is when we have dirtied large
> number of small files in kind-of random order and submitted them
> down to disk.
>
> Per-mapping sorting will not do anything good in this case, even if
> files were previously created in a good facion being placed closely and
> so on, and only block layer will find a correlation between adjacent
> blocks in different files. But with existing queue management it has
> quite a small opportunity, and that's what I think Andrew is arguing
> about.
