On Fri, 18 Dec 2009 10:12:22 -0500 Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > On Fri, 2009-12-18 at 09:47 -0500, Trond Myklebust wrote: > > On Fri, 2009-12-18 at 09:39 -0500, Jeff Layton wrote: > > > Without a separate downcall error field, we'll need to special case at > > > least 2 different errors -- one for a "real" EACCES and one that > > > indicates that the ticket expired and the upcall should be retried > > > instead. > > > > We can find another error for the 'ticket expired' case. EKEYEXPIRED > > springs to mind... > > BTW: Here be dragons! > > I think we need to handle the 'ticket expired' case as if it were an > NFS4ERR_DELAY/EJUKEBOX, and actually do the retry in the NFS layer after > a suitable exponential back-off period. > > Otherwise, we end up holding onto resources (in particular NFSv4.1 > slots, but also RPC slots, ...) which will cause congestion, and prevent > other RPC calls from making progress. > Thanks. My original thought was that we should handle this situation as we do when gssd is down -- just retry at the RPC layer. I hadn't considered the resource issue however. I'll shoot for making the retry happen at the NFS layer instead. That should also make it easier to handle this situation differently on hard vs. soft mounts too. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
