Re: [RFC PATCH 0/6] nfs-utils: Improving NFS re-exports

[bfields <bfields@fieldses.org>]

On Thu, Feb 17, 2022 at 09:15:38PM +0100, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "bfields" <bfields@fieldses.org>
> >> 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.