On Thu, Jun 24, 2021 at 09:29:01AM +1000, NeilBrown wrote: > On Thu, 24 Jun 2021, J. Bruce Fields wrote: > > On Thu, Jun 24, 2021 at 08:04:57AM +1000, NeilBrown wrote: > > > 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. Yeah, that's why this is on my mind. Currently we can only re-export filesystems that are explicitly mounted and exported with an fsid= option. I had an idea that it would be interesting to run nfsd in a mode where all it does is re-export everything exported by one single server. In theory then you no longer need to do any encapsulation, so you avoid the maximum-filehandle-length problem. When you get an unfamiliar filehandle, you pass it on to the original server and get back an fsid, and if it's one you haven't seen before you have to cook up a new vfsmount and stuff somehow. I ran aground trying to understand how to do that in a way that wasn't too complicated. Anyway. --b. > 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. > > > > > > 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
