> On Sat, 28 Aug 2021, Frank Filz wrote: > > > > On Sat, 28 Aug 2021, Frank Filz wrote: > > > > > > > > Changing the fsid for sub-volumes is Ganesha's solution (before > > > > adding that, we couldn't even export the sub-volumes at all). > > > > > > What does Ganesha use for the mounted-on-fileid? There doesn't seem > > > to be an "obvious" answer so I wonder what was chosen. > > > > We only make mounted_on_fileid different from fileid on our export > > boundaries, and even then, it's not a terribly correct thing for > > FSAL_VFS (our module for interfacing with kernel filesystems) since > > user space to my knowledge has no way to get any information on an > > inode that serves as a mount point. > > It is possible to see the mounted-on inode number by doing a readdir() of the > parent directory and looking at d_ino. It is a bit round-about. Ahh, I'll have to keep that in mind, I'm not totally sure, but I think AIX mostly used/got the mounted_on_fileid during a READDIR which if that translates into a readdir to the underlying filesystem (via getdents in our case) then we have the d_ino to fill in mounted_on_fileid. I think it's less likely a situation with a LOOKUP. I think AIX used it when it got NFS4ERR_WRONGSEC when doing a READDIR, it would then go back and do a READDIR just asking for mounted_on_fileid (which as a property of the owning directory, we decided was OK to give for an inode that was in a new export with different security flavor requirements). I think AIX used the mounted_on_fileid to instantiate some kind of junction inode in the directory. > > > > What clients actually do anything with mounted_on_fileid, and what > > sorts of things do they do with it? I know the AIX client was > > interested in it (from having worked on security negotiation back in > > 2006), but I have never been able to test Ganesha with an AIX client. > > For normal Linux client operations, what Ganesha does seems to work > > OK. > > On the Linux client, if you stat() a directory that is a mountpoint on the server, > you will see a directory with the inode number being the mounted-on-fileid. > That directory is an automount-point, and when you access anything in it, the > 'real' directory gets mounted and the mounted-on-fileid disappears. > So if you reported a mounted-on-fileid the same as the fileid, which would be > 256 on btrfs, du and find can get confused. To be safe, the mounted-of-fileid > needs to be different to all ancestors. > > NeilBrown Frank
