On 2010-02-20, at 13:13, Brad Boyer wrote:
On Sat, Feb 20, 2010 at 11:58:34AM -0700, Andreas Dilger wrote:
Without the handle identifying the filesystem in some way this is
mostly useless. Encoding the device number would be a simple (though
non-robust) way to do this, a better way would be with the filesystem
UUID and adding an in-kernel UUID->sb mapping function (which is
useful for other things as well).
I certainly have one use in mind for having a static sb->ID mapping
inside the FS driver.
One use I've had for this in the past, then never managed to finish
the work is for in-kernel identification of multi-device filesystems.
For example, ext3/4 can have an external journal, and currently the
journal device is identified by the UUID but we also have to add a
"hint" for the kernel for finding it by devno. This can fail on
occasion when devices are renamed.
It seems like a more reliable way to do NFS
serving of anything more complicated than a standard disk-based
local filesystem. In particular, it would be nice to be able to
serve some synthetic or network/cluster based FS over NFS and have
the file handles be consistent across multiple machines for failover
purposes. Currently specifying the fsid in the exports table is the
only logical way to force this, but that's extra manual work.
Yes, we looked at this in the past for Lustre as well, and while we
had proposed a patch for the NFSd code to extract the FSID from the
filesystem, it was turned down because "setting the FSID via a
userspace file is the right thing to do". I have enough on my plate
not to wage an uphill battle for this.
I don't necessarily agree, because that means administering yet
another config parameter outside the filesystem on all of the
servers. I don't mind allowing userspace to override the fs UUID-
based FSID, but why not let this be used by default instead of the
devno (which is increasingly dynamic these days).
Maybe with more clustered filesystems in the kernel these days this
idea can gain more traction.
I haven't started writing any code to do this, but I have looked
at the current NFS FH code and it seems like it should be reasonable
to add a new set of methods to allow another FS specific field.
First would be a method to extract the FSID/UUID from the filesystem.
That is immediately useful for even local configs.
The hardest part seems to be holding the size down to the old NFS v2
protocol limits.
Would it not be possible to encode the FSID/UUID only into NFSv3/v4
handles, and leave the NFSv2 handles without this information? I
imagine the usage of NFSv2 is growing ever smaller, and there isn't a
requirement to add this extra field there.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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
