Hi, On Mon, Oct 06, 2008 at 05:14:02PM -0400, Theodore Tso wrote: > On Mon, Oct 06, 2008 at 12:35:06PM +0100, steve@xxxxxxxxxxx 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? > Yes, that sounds ok to me. > 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 No, we don't need anything else special. So far as GFS2 is concerned it only uses a single device. If there is a requirement for anything more complicated, we leave that to lvm etc. I don't know what the requirements are for the other filesystems you mention in that area. The original plan was, that if anything complicated was required in terms of fs layout, then we'd get mkfs to do that at fs create time based on info which it might query from the underlying device. To date though we've not implemented anything like that, so its still fairly simple, Steve. -- 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
