[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