On Sun, Feb 21, 2010 at 11:42:45AM -0700, Andreas Dilger wrote: > 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. I'm trying to understand your expectations here. Do you mean that you want to be able to search for a block device object in the kernel by UUID? I'm not saying it wouldn't be useful to have that, but I do want a feel for what would be involved. Wouldn't it be easier to have a custom mount.ext3 and mount.ext4 that use libblkid to find the journal device? > >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. It's good to see that someone else already thought of this and that I'm not crazy for wanting it. > 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. It does seem like a logical use case to have a cluster FS supply its own FSID, since it probably knows better than the kernel how to actually specify uniqueness. The only complexity is making sure it's possible to tell the difference between that and one the kernel generates. Having to set the FSID in the exports table on a large cluster for a large number of exports is a pain. This is doubly true if any of it was supposed to be automated in terms of adding new exports. I know some people working on a NAS-type box with built-in failover based on Linux and they ran into this problem, and they have to generate fsid values in their management scripts because of this. > >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. Seems like a simple thing to add, but what would be a simple usage that would be likely to be considered useful? A new feature without any users is not going to be welcomed. > >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. It's certainly an option, but it would be nice to support the older protocol as well if it's possible. Brad Boyer flar@xxxxxxxxxxxxx -- 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
