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). 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. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
