On Sun, Feb 28, 2010 at 10:55:34AM -0700, Andreas Dilger wrote: > On 2010-02-26, at 12:21, J. Bruce Fields wrote: >> 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 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'm not sure what you mean? With recent mountd and kernel, knfsd generates filehandles using a uuid passed down from mountd, which mountd gets from libblkid. > On the clients (where the NFS servers are > running) there are no block devices, so I don't think libblkid is > relevant. Oh, OK. (Though for a shared-disk cluster-filesystem it should be enough, yes?) > Lustre itself already can provide a UUID/fsid that is the > same on all clients, but there is no way to pass this to NFSd. > > If there is interest to revive this idea, I'll try to dig up the old > patches we had. I believe that they set a FS_NFS_FSID (or similarly > named) flag in the file_system_type, and possibly a method that > extracted this information for NFSd. OK, sure, but if it's only of use to lustre than I don't see how to justify a kernel patch. Another option would be to provide an alternative to nfs-utils/utils/mountd/cache.c's get_uuid() that can request the filesystem's uuid (assuming you've got an easy way to get it from userspace). That might also save having to add yet another case to e.g. fs/nfsd/nfsfh.c:set_version_and_fsid_type(). --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
