On Sun, Feb 21, 2010 at 11:42:45AM -0700, Andreas Dilger wrote: > 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 agree that a cluster filesystem shouldn't need fsid= set right across all servers. But doesn't the libblkid uuid stuff as it's now implemented give you what you need? >> 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. Yeah, I don't think NFSv2 support should be a high priority for new features. --b. -- 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
