> 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. 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. > > > > Mangling the fileid is definitely the best solution if there will be lots of sub- > volumes. For a few sub-volumes changing fsid does create additional mount > points on the client with some issues, but does guarantee there will be no fileid > collision. > > > > My gut feel is your solution is the best one and Ganesha may need to switch to > that solution. > > Thanks for the encouragement. Changing the fsid does seem easier is many > ways, but I don't really like the consequences or implications. Yea, there really isn't a good solution here. Probably really client applications need to do something different to detect infinite loops and not care so much about unique fileids. Frank
