On Thu, Feb 17, 2022 at 09:15:38PM +0100, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > Von: "bfields" <bfields@xxxxxxxxxxxx> > >> Which one do you prefer? > >> "predefined-fsidnum" should be the safest one to start. > > > > I don't know! I'll have to do some more reading and think about it. > > No need to worry, take your time. > > >> > Setting the timeout to 0 doesn't help with re-export server reboots. > >> > After a reboot is another case where we could end up in a situation > >> > where a client hands us a filehandle for a filesystem that isn't mounted > >> > yet. > >> > > >> > I think you want to keep a path with each entry in the database. When > >> > mountd gets a request for a filesystem it hasn't seen before, it stats > >> > that path, which should trigger the automounts. > >> > >> I have implemented that already. This feature is part of this series. :-) > > > > Oh, good, got it. It'll take me some time to catch up. > > The reason why setting the timeout to 0 is still needed is because > when mountd uncovers a subvolume but no client uses it a filehandle, > it is not locked and can be unmounted later. > Only when nfsd sees a matching filehandle the reference counter will > be increased and umounting is no longer possible. I understand that. But, then if a client comes in with a matching filehandle, mountd should be able to look up the filesystem and trigger a new mount, right? I can imagine that setting the timeout to 0 might be an optimization, but I'm not seeing why it's required for correct behavior. --b.
