Ganesha can handle all the state stuff at the protocol level using whatever state support the FSAL has. Your response does make me think of an issue though. Let’s say an export was v3 and v4 and will be updated to v3 only. If we unexport, and then re-export, we lose all that v3 state without any way to trigger client reclaim. The same would be true of v3/v4 to v4 only. A restart would trigger the normal client state reclaim, and the clients that can no longer access the export (because the version they were using is no longer supported by the export) would get errors during state reclaim. If we want to handle this kind of change without restart, we need to remove all state associated with the NFS version that is no longer supported. An issue here is that the way state_export_unlock_all() works is that it drains the list of all locks on the export (using glist_first_entry followed by glist_del), it isn’t prepared to only remove the only the v3 or only the v4 locks. One thing that could be done there is if we are removing v3 but not v4 locks (or visa versa), move the v4 locks to the end of the list and if we also had a count of entries in the list, but then we need a way of knowing that we have processed all the locks (one way would be to put a fake lock at the end of the list and when we hit that, we have processed all the locks that existed when we started. We can then, while holding the lock, iterate over the list and verify there are no more v3 locks, and if there are, move the fake lock back to the end, and iterate again. No new locks should be granted if we shut down the v3 access before removing the v3 locks. Another monkey wrench, we also have 9P in this equation, where there is no client state reclaim so we really don’t want to have to restart. I think this is a solvable problem, but sure is messy… Frank From: Solomon Boulos [mailto:boulos@google.com] Sent: Thursday, March 19, 2020 6:49 PM To: Frank Filz <ffilzlnx(a)mindspring.com&gt; Cc: devel(a)lists.nfs-ganesha.org; Sriram Patil <sriramp(a)vmware.com>; Jeff Layton <jlayton(a)redhat.com&gt; Subject: Re: [NFS-Ganesha-Devel] Issues with Changing pseudo path of an export Assuming you're saying "dynamically tell the FSAL, hey, I'm changing Protocols to just V4 now", how would that work for say v3/NLM lock state? For NLM, you can't just drop the information as someone needs to go through each lock and < do something >. The most obvious would be to pretend that the server crashed, disable v3, and then allow recovery to proceed. Adding a protocol might be easier. For the V4 Proxy, I think it also only (optionally) builds up V3 filehandles on demand, and those would presumably not have been setup during the "I was just being a V4 proxy until you came along" preamble. Other in-tree FSALs don't seem to care much about V3 vs V4 client-ness. Though on that note, I don't see a particularly good way for my new V3 proxy to allow V4 clients (and it would be nice to signal as such to the upper layers). At the very least, it seems like you'd need to ask FSALs if they can be adjusted like this, and if not, do an un-export followed by create_export (but in the interim claim to be in grace?).

If a pseudo path changes, ideally the file handle should be correct and returning 'stale file handle' is a bug. We should be able to return stale state though and the client should do the right thing. File handle has version in it, so returning stale file handle is OK if the export version changes. If an admin wants to remove an export or its version, it is OK to honor him and return stale file handle, correct? Regards, Malahal. On Fri, Mar 20, 2020 at 5:01 AM Frank Filz <ffilzlnx(a)mindspring.com&gt; wrote: