linux-nfs-owner@xxxxxxxxxxxxxxx wrote on 10/17/2008 10:44:54 AM: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> > > On Wed, Oct 15, 2008 at 05:00:23PM -0400, andros@xxxxxxxxxx wrote: > > Here's a patch set for review - it compiles and seems to work, butI haven't > > done stress testing, nor testing of all of the combinations of > deferral cases. > > > > A deferral occurs when NFSD needs information from an rpc cache, > and an upcall > > is required. Instead of NFSD waiting for the cache to be filled by > the upcall, > > the RPC request is inserted back into the receive stream for processing at a > > later time. > > > > Exactly once semantics require that NFSD compound RPC deferral processing > > restart at the operation that caused the deferral, instead of > reprocessing the > > full compound RPC from the start possibly repeating operation processing. > > These patches add three callbacks, a data pointer, and page pointer storage > > to the sunrpc svc deferral architecture that NFSD uses to > accomplish this goal. > > > > Deferrals that do not define the callbacks act as before. Care hasbeen taken > > to ensure that combinations of deferrals - those from the NFSv4 server with > > the callbacks defined, and those from the RPC layer without the callbacks > > defined work together correctly. > > > > Thoughts, comments and suggestions are really appreciated... > > Requests longer than a page are still not deferred, so large writes that > trigger upcalls still get an ERR_DELAY. OK, probably no big deal. > > I don't think we can apply this until we have some way to track the > number and size of deferred requests outstanding and fall back on > ERR_DELAY if it's too much. But I thought that the problem here is that the Linux NFS client doesn't handle this return code properly. Marc. > > I do sometimes wonder whether continuing with the current > deferred-request approach is best, though: > > - If we're saving out large parts of the request anyway (the > response pages), then maybe we should just keep rqstp's > on the deferred request queue instead of copying to a separate > deferred_request structure. > - Then as long as we're saving all that request data, is there > really significant savings from not keeping a thread around > too? > > So I wonder if it'd be better just to let threads sleep (and be more > aggressive about starting up new threads if appropriate, and add some > other heuristics to avoid a situation where the whole server stalls on a > temporarily wedged userspace daemon). > > --b. > -- > 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 -- 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
