Re: What to do about subvolumes?

["J. Bruce Fields" <bfields@redhat.com>]

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.