On Thu, Apr 18, 2019 at 10:03:09PM +0000, Trond Myklebust wrote: > On Thu, 2019-04-18 at 16:50 -0400, Scott Mayhew wrote: > > On Thu, 18 Apr 2019, J. Bruce Fields wrote: > > > > > On Thu, Apr 18, 2019 at 09:24:00AM -0400, Scott Mayhew wrote: > > > > While trying to track down some issues involving large numbers of > > > > delegations being recalled/revoked, I caught the server setting > > > > SEQ4_STATUS_CB_PATH_DOWN while the client was actively responding > > > > to > > > > CB_RECALLs. It turns out that the client had already done a > > > > TEST_STATEID and FREE_STATEID for a delegation being recalled by > > > > the > > > > time it received the CB_RECALL. > > > > > > That's interesting, thanks! > > > > > > This exception seems awfully narrow, though. > > > > > > If we get back any NFS-level error at all, then I think the > > > callback > > > channel is working (am I wrong?) > > > > Correct, if the client replies with either NFS4ERR_DELAY or > > NFS4ERR_BAD_STATEID, the server will retry 1 time (see dl_retries). > > After that, we fall thru and nfsd4_cb_recall_done() returns -1 which > > causes the SEQ4_STATUS_CB_PATH_DOWN flag to be set. > > There is no handling of NFS4ERR_DELAY in nfsd4_cb_recall_done(). > > As far as I can see, therefore, if the client returns NFS4ERR_DELAY > (which it usually does if it is already in the process of returning the > delegation) then the recall will fail immediately. We should fix that, though it doesn't sound like it matters much in that particular case. The success or failure of a recall isn't actually all that interesting, all that matters is whether we get the eventual DELEGRETURN. --b.
