Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     "Wang Yugui" <wangyugui@e16-tech.com>, linux-nfs@vger.kernel.org
Subject: Re: any idea about auto export multiple btrfs snapshots?
In-reply-to: <20210623153548.GF20232@fieldses.org>
References: <162432531379.17441.15110145423567943074@noble.neil.brown.name>,
 <20210622112253.DAEE.409509F4@e16-tech.com>,
 <20210622151407.C002.409509F4@e16-tech.com>,
 <162440994038.28671.7338874000115610814@noble.neil.brown.name>,
 <20210623153548.GF20232@fieldses.org>
Date:   Thu, 24 Jun 2021 08:04:57 +1000
Message-id: <162448589701.28671.8402117125966499268@noble.neil.brown.name>
Precedence: bulk

On Thu, 24 Jun 2021, J. Bruce Fields wrote:
> Is there any hope of solving this problem within btrfs?
> 
> It doesn't seem like it should have been that difficult for it to give
> subvolumes separate superblocks and vfsmounts.
> 
> But this has come up before, and I think the answer may have been that
> it's just too late to fix.

It is never too late to do the right thing!

Probably the best approach to fixing this completely on the btrfs side
would be to copy the auto-mount approach used in NFS.  NFS sees multiple
different volumes on the server and transparently creates new vfsmounts,
using the automount infrastructure to mount and unmount them.  BTRFS
effective sees multiple volumes on the block device and could do the
same thing.

I can only think of one change to the user-space API (other than
/proc/mounts contents) that this would cause and I suspect it could be
resolved if needed.

Currently when you 'stat' the mountpoint of a btrfs subvol you see the
root of that subvol.  However when you 'stat' the mountpoint of an NFS
sub-filesystem (before any access below there) you see the mountpoint
(s_dev matches the parent).  This is how automounts are expected to work
and if btrfs were switched to use automounts for subvols, stating the
mountpoint would initially show the mountpoint, not the subvol root.

If this were seen to be a problem I doubt it would be hard to add
optional functionality to automount so that 'stat' triggers the mount.

All we really need is:
1/ someone to write the code
2/ someone to review the code
3/ someone to accept the code

How hard can it be :-)

NeilBrown