Re: query related to write_mapping_buffers

[Andrew Morton <akpm@digeo.com>]

Kapish K wrote:
> 
> Hello,
>   I have tried to understand this part, and
> must confess I haven't been able to get a
> clear idea of the logic/reasoning behind this.
> What does write_mapping_buffers and
> mpage_writepages attempt to write out?

Consider the case of writing a single large ext2 file.
Ideally, it will be laid out on disk as 1024 data blocks
then one indirect block, then 1024 data blocks then one
indirect block, etc.

We want to send them to disk in that order to avoid any
unnecessary seeking.

That happens naturally in the 2.4 kernel because writeout
occurs against the dirty block LRU - blocks are sent to disk in
the order in which they were dirtied.

But in 2.5, writeout occurs on a per-inode basis.  And the
file data are in a different inode from the indirect blocks.

The idea was that write_mapping_buffers() would submit the
indirect blocks for writes, and mpage_writepages() would
submit the data and they would get merged nicely together
at the disk request layer.

It worked OK for most things, but didn't work right for 
really large files.  So write_mapping_buffers() was removed
in a later kernel.  Now, mpage_writepage() will use the
`buffer_boundary()' IO scheduling hint to determine that
a data block probably has a neighbouring dirty metadata
block.  It will call write_boundary_block() at the appropriate
time to try to locate that block, and start IO against it.

Net effect: the indirect blocks and data blocks are all smoothly
and linearly sent to disk.

It's a bit awkward - that natural scheduling of IO against different
inodes is something we lost when the global buffer LRU was removed.