Re: [PATCH 3/4] generic block based fiemap implementation

[Theodore Tso <tytso@mit.edu>]

On Mon, Oct 06, 2008 at 12:35:06PM +0100, steve@chygwyn.com wrote:
> 
> Would it be possible to move the inode mutex out of generic_block_fiemap()
> and into the callers? The defined lock ordering in GFS2 is inode mutex ->
> inode glock, and thus we want to be able to lock in that order. We should
> be able to use generic_block_fiemap() for GFS2 in that case. 

Given that nearly all other block-based filesystems that don't use
extents would need to take the mutex lock, this would be error-prone.
What about introducing an _generic_block_fiemap() for use by GFS2 that
doesn't the inode mutex, and changing generic_block_fiemap() to be a
wrapper that calls _generic_block_fiemap() and takes the inode mutex
for the convenience of most other filesystems?

This would be a very simple change to make once a patch to enable GFS2
use of the FIEMAP interface.  (If we introduce
_generic_block_fiemap(), it's likely to get removed by some random
roving Kernel Janitor, as an exported but unused interface.  :-)

It occurs to me though that this is likely not all that is needed for
GFS2, though, since like Lustre, BTRFS, and ZFS, there can be multiple
disks or storage devices associated with a single filesystem, correct?
So we would need to add some way of identifying the disk, not just the
block number; how does GFS2 identify/enumerate storage devices which
are part of a particular filesystem?

        					- Ted