Re: [PATCH 1/7] ext4: ext4_inode_info diet

[Theodore Ts'o <tytso@mit.edu>]

On Thu, Sep 13, 2012 at 03:15:40PM +0400, Dmitry Monakhov wrote:
> Current buffer.c API layering looks sub-optimal
> 
> ->xxx_fs_routine: May create different contexts
>    ->generic_buffer_methods(inode, bh..)
>      ->xxx_fs_get_block(inode, bh,...): There is no efficient way to pass fscontext 
> Both xxx_fs_routine and xxx_fs_get_block are fs specific, but
> the only way to pass fscontext down to get_block is to pass it by
> attaching it to inode, which make it implicit serialization point.
> 
> I just want to add fsprivate argument to get_block_t callback similar
> write_begin/write_end and iocb->private, so filesystem will able to pass
> it to it's get_block callback.

If we're going to change the function prototype for get_block_t, it
might also be good to fix a long-standing ugliness with this interface
which is that the get_block() interface does two very different things
when bh->b_size is greater a single block.  If b_size is a greater a
block, then instead of bh being a "real" buffer_head, it's a pseudo
map_bh.  This is annoying because map_bh is generally allocated on the
stack, but most of the fields are unused, since it's not really a
_real_ buffer_head, but just a countainer for a handful of fields used
by the AIO/DIO and mpage.c functions.

Instead of changing get_block(), which would require lots of changes
all over the kernel, what I'd suggest doing instead is creating a new
function which I'd propose calling get_map() which fills in a new
structure which replaces map_bh, and which includes the aio_dio
structure.  It could be made mandatory for the few file systems which
support DIO, but that way we don't havec to change the dozens of other
file systems which don't use the DIO code paths.

Regards,

					- Ted