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. > > 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
