Re: What to do about subvolumes?

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

On Wed, Dec 08, 2010 at 09:41:33PM -0700, Andreas Dilger wrote:
> On 2010-12-08, at 16:07, Neil Brown wrote:
> > On Mon, 6 Dec 2010 11:48:45 -0500 "J. Bruce Fields" <bfields@redhat.com>
> > wrote:
> > 
> >> On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote:
> >>> Any chance we can add a ->get_fsid(sb, inode) method to
> >>> export_operations (or something simiar), that allows the
> >>> filesystem to generate an FSID based on the volume and
> >>> inode that is being exported?
> >> 
> >> No objection from here.
> > 
> > My standard objection here is that you cannot guarantee that the
> > fsid is 100% guarantied to be unique across all filesystems in
> > the system (including filesystems mounted from dm snapshots of
> > filesystems that are currently mounted).  NFSd needs this uniqueness.
> 
> Sure, but you also cannot guarantee that the devno is constant across reboots, yet NFS continues to use this much-less-constant value...
> 
> > This is only really an objection if user-space cannot over-ride
> > the fsid provided by the filesystem.
> 
> Agreed.  It definitely makes sense to allow this, for whatever strange circumstances might arise.  However, defaulting to using the filesystem UUID definitely makes the most sense, and looking at the nfs-utils mountd code, it seems that this is already standard behaviour for local block devices (excluding "btrfs" filesystems).
> 
> > I'd be very happy to see an interface to user-space whereby
> > user-space can get a reasonably unique fsid for a given
> > filesystem.
> 
> Hmm, maybe I'm missing something, but why does userspace need to be able to get this value?  I would think that nfsd gets it from the filesystem directly in the kernel, but if a "uuid=" option is present in the exports file that is preferentially used over the value from the filesystem.

Well, the kernel can't distinguish the case of an explicit "uuid="
option in /etc/exports from one that was (as is the normal default)
generated automatically by mountd.  Maybe not a big deal.

The uuid seems like a useful thing to have access to from userspace
anyway, for userspace nfs servers if for no other reason:

> That said, I think Aneesh's open_by_handle patchset also made the UUID visible in /proc/<pid>/mountinfo, after the filesystems stored it in
> sb->s_uuid at mount time.  That _should_ make it visible for non-block mountpoints as well, assuming they fill in s_uuid.
> 
> > Whether this is an export_operations method or some field in the
> > 'struct super' which gets copied out doesn't matter to me.
> 
> Since Aneesh has already developed patches, is there any objection to using those (last sent to linux-fsdevel on 2010-10-29):
> 
> [PATCH -V22 12/14] vfs: Export file system uuid via /proc/<pid>/mountinfo
> [PATCH -V22 13/14] ext3: Copy fs UUID to superblock.
> [PATCH -V22 14/14] ext4: Copy fs UUID to superblock

I can't see anything wrong with that.

--b.