On Thu, 24 Jun 2021, J. Bruce Fields wrote:

On Thu, Jun 24, 2021 at 08:04:57AM +1000, NeilBrown wrote:

quoted

On Thu, 24 Jun 2021, J. Bruce Fields wrote:

One other thing I'm not sure about: how do cold cache lookups of
filehandles for (possibly not-yet-mounted) subvolumes work?

Ahhhh...  that's a good point.  Filehandle lookup depends on the target
filesystem being mounted.  NFS exporting filesystems which are
auto-mounted on demand would be ... interesting.

That argues in favour of nfsd treating a btrfs filesystem as a single
filesystem and gaining some knowledge about different subvolumes within
a filesystem.

This has implications for NFS re-export.  If a filehandle is received
for an NFS filesystem that needs to be automounted, I expect it would
fail.

Or do we want to introduce a third level in the filehandle: filesystem,
subvol, inode.  So just the "filesystem" is used to look things up in
/proc/mounts, but "filesystem+subvol" is used to determine the fsid.

Maybe another way to state this is that the filesystem could identify a
number of bytes from the fs-local part of the filehandle that should be
mixed in to the fsid.  That might be a reasonably clean interface.

quoted

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

Hah.  Still, the special exceptions for btrfs seem to be accumulating.
I wonder if that's happening outside nfs as well.

I have some colleagues who work on btrfs and based on my occasional
discussions, I think that: yes, btrfs is a bit "special".  There are a
number of corner-cases where it doesn't quite behave how one would hope.
This is probably inevitable given they way it is pushing the boundaries
of functionality.  It can be a challenge to determine if that "hope" is
actually reasonable, and to figure out a good solution that meets the
need cleanly without imposing performance burdens elsewhere.

NeilBrown