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". -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
