1:06 p.m.
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>
Cc: devel(a)lists.nfs-ganesha.org; Sriram Patil <sriramp(a)vmware.com>; Jeff Layton
<jlayton(a)redhat.com>
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?).