Re: [PATCH 00/12] Some improvements to request deferral and related code

J. Bruce Fields
2009-08-10T15:05:00Z

On Fri, Aug 07, 2009 at 02:13:50PM +1000, Neil Brown wrote:
> On Tuesday August 4, bfields@fieldses.org wrote:
> > On Tue, Aug 04, 2009 at 03:22:38PM +1000, NeilBrown wrote:
> > > This series fixes a few little bugs and tidies up some code but does
> > > two main important things.
> > >
> > > 1/ 'allow thread to block....' will wait a little while if there is a
> > > cache miss. If an answer is available in that time, it continues on
> > > it's merry way. If no answer arrives, the old deferral approach is
> > > used. It waits 5 seconds if there are spare nfsd threads, and 1
> > > second if there all threads are busy. I have almost nothing with
> > > which to justify these numbers.
> >
> > I think the v4 server at least should return NFS4ERR_DELAY in this case
> > instead of doing the internal replay. That avoids possible problems
> > with non-idempotent compound ops.
>
> If the request has been handed to nfsd, then yes I agree. We probably
> want some way for nfsd to mark the request as "don't replay" so that
> an error will propagate out. Currently we map that error to EJUKEBOX
> for v3 or v4, but you are right, we want ERR_DELAY for v4.

Note actually DELAY and JUKEBOX are both 10008--the v4 spec just renamed
it.

> If the request is still in the RPC code (trying to identify the
> origin or to decode the crypto) then we cannot return ERR_DELAY, but
> as none of the request will have been processed yet, there is no room
> for a problem with non-idempotent ops.
>
> It has occurred to me that we could throw away the current request
> deferral completely: if we don't feel comfortable delaying the thread
> for as long as it takes, we just return an error or drop the request
> (closing any connection).
> I'm not sure I'd be comfortable doing that if there were only a few
> (8?) threads though.
> Maybe if we got dynamic nfsd threads so that new ones could be created
> on demand I would feel quite happy to discard the deferral stuff and
> just use a delay.

How about just increasing the default number of threads for now?

--b.

>
> >
> > >From the protocol point of view I don't know if there's any rule of
> > thumb about when it'd be best to return DELAY. Perhaps it's best to
> > avoid it whenever possible, but when the delay is on the order of
> > seconds it sounds reasonable to me.
>
> Of course you don't know how long the delay will be until it happens:-)
>
> But I agree. Delay internally if possible, but as soon as that seems
> to be awkward (e.g. run out of threads), return DELAY
>
> Thanks,
> NeilBrown
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html