Re: [RFC][PATCH] expose get_block via inode_operations

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Apr 22, 2008 at 02:18:24PM -0400, Josef Bacik wrote:
> Hello,
> 
> In order to add a generic FIEMAP support for all filesystems that do not
> necessarily have extents (ie ext2/3), it is necessary to have direct access to
> the filesystems get_block function.  The reason for this is because in certain
> cases (again ext2/3) the filesystem has the ability to map as many contiguous
> blocks together at once, which would be far more efficient than calling ->bmap()
> over and over for all of the blocks in the inode.  In order to accomplish this I
> would like to expose the filesystems get_block function via an inode operation.
> This would allow me to create a simple generic FIEMAP function that could be
> used on all fs's and be a bit more efficient that FIBMAP, and it would clean up
> where we are passing get_block_t everywhere.

ITYM "bugger up".  Strong NAK; do not breed methods that do not even make
sense for a lot of class instances.

This, BTW, is a general principle - the same reason why ->read_inode() is
gone, for example.

If you have a function that needs fs-dependent callback and can be safely
called only by specific fs (== relies on fs properties), by all means,
make it a library helper and have your fs call it.  Passing whatever
callbacks it wants explicitly.  With fs being responsible for choosing
to use that library helper.

get_block semantics can't be even defined for generic filesystem; it's not
that "this fs or this file doesn't do that operation", it's "operation can't
be defined in terms that make sense for all filesystems".