On Wed, Dec 08, 2010 at 10:16:29AM -0700, Andreas Dilger wrote: > On 2010-12-07, at 10:02, Trond Myklebust wrote: > > > On Tue, 2010-12-07 at 17:51 +0100, Christoph Hellwig wrote: > >> It's just as stable as a real dev_t in the times of hotplug and udev. > >> As long as you don't touch anything including not upgrading the kernel > >> it's remain stable, otherwise it will break. That's why modern > >> nfs-utils default to using the uuid-based filehandle schemes instead of > >> the dev_t based ones. At least that's what I told - I really hope it's > >> using the real UUIDs from the filesystem and not the horrible fsid hack > >> that was once added - for some filesystems like XFS that field does not > >> actually have any relation to the UUID historically. And while we > >> could have changed that it's too late now that nfs was hacked into > >> abusing that field. > > > > IIRC, NFS uses the full true uuid for NFSv3 and NFSv4 filehandles, but > > they won't fit into the NFSv2 32-byte filehandles, so there is an > > '8-byte fsid' and '4-byte fsid + inode number' workaround for that... > > > > See the mk_fsid() helper in fs/nfsd/nfsfh.h > > It looks like mk_fsid() is only actually using the UUID if it is specified in the /etc/exports file (AFAICS, this depends on ex_uuid being set from a uuid="..." option). No, if you look at the nfs-utils source you'll find mountd sets a uuid by default (in utils/mountd/cache.c:uuid_by_path()). > There was a patch in the open_by_handle() patch series that added an s_uuid field to the superblock, that could be used if no uuid= option is specified in the /etc/exports file. Agreed that doing this in the kernel would probably be simpler. --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
