[pnfs] [PATCH 9/9] pnfs client prevent race in sequence slot
Iyer, Rahul
Rahul.Iyer at netapp.com
Thu Sep 27 14:23:15 EDT 2007
> -----Original Message-----
> From: Trond Myklebust [mailto:trond.myklebust at fys.uio.no]
> Sent: Thursday, September 27, 2007 11:05 AM
> To: Benny Halevy
> Cc: pnfs at linux-nfs.org; andros at umich.edu
> Subject: Re: [pnfs] [PATCH 9/9] pnfs client prevent race in
> sequence slot
>
> On Thu, 2007-09-27 at 17:38 +0200, Benny Halevy wrote:
>
> > I'm afraid there might be more into that. For example, if the
> > interrupted rpc was stateid changing you have to process
> the reply to
> > stay in sync with the server so in general I still think the client
> > must process the reply regardless of whether whoever
> generated the rpc
> > is waiting for it or not. This means that if an rpc is
> interrupted we
> > need to return -EINTR upstream and postpone the processing
> of the rpc
> > reply as if it was an async rpc even if it started as synchronous
> > rather than try to second guess the server by probing it. (it could
> > have been easier if there was a way to officially try to cancel an
> > outstanding rpc...)
>
> That should not be a problem if you guys have followed the
> existing prescription of always using asynchronous RPC calls
> for stateful operations. Those are always guaranteed to complete.
>
This can be a problem because it converts nearly every rpc into an async
call as there's a sequence op in almost every one of them.
-Rahul
> Normally, the only case we have to worry about is the
> synchronous calls.
>
> Trond
>
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>
More information about the pNFS
mailing list