query related to write_mapping_buffers

query related to write_mapping_buffers

[Kapish K]

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? in
terms of kind of data or pages and why are
both needed?
ext2_writepages calls write_mapping_buffers
first and then mpage_writepages ( my
reference is 2.5.30 )
The comment in write_mapping_buffers does
say that it writes back indirect blocks (
metadata? ), but I am not sure I get the
whole idea. 
Any hints on this that might help understand
this better will be most appreciated
Thanks In Advance

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

Re: query related to write_mapping_buffers

[Andrew Morton]

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.