[pnfs] [PATCH 9/9] pnfs client prevent race in sequence slot

William A. (Andy) Adamson andros at citi.umich.edu
Thu Sep 27 15:53:14 EDT 2007


On 9/27/07, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
>
> On Thu, 2007-09-27 at 15:12 -0400, Trond Myklebust wrote:
> > On Thu, 2007-09-27 at 15:00 -0400, William A. (Andy) Adamson wrote:
> > >
> > >
> > > On 9/26/07, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> > >         If we have to interrupt an RPC call, then we immediately fire
> > >         off an
> > >         asynchronous RPC call with a single SEQUENCE call that uses
> > >         the _same_
> > >         sa_sequence id as the synchronous RPC call that was cancelled
> > >         (and drops
> > >         all the other arguments).
> > >
> > > ok. but can't we get around sending yet another rpc by looking at what
> > > the server has already sent (or not)?  we do have all the information.
> >
> > I don't understand. If you have a reply, then you're not interrupting an
> > RPC call,

however the fact that you don't have a reply means nothing:
> > assuming that an RPC call was actually sent by the client then the
> > server may or may not have received it (we just don't know until we have
> > a reply).
>
> Oh... I think I see your point. Are you perhaps suggesting that we just
> look for the NFS4ERR_SEQ_MISORDERED reply, and use that as to indicate
> that the server didn't see our previous RPC call on that slot?
> That might work too.


yes, just remember in the slot that the RPC with seq# was interrupted and
reset the slot sequence number iff MISORDERED err on seq#+1.

-->Andy

Trond
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20070927/d6538143/attachment.htm 


More information about the pNFS mailing list