[Spam-fortigate] Re: NFSv4 client's BUG?

[J. Bruce Fields]

On Wed, Jul 16, 2008 at 03:05:41PM -0400, Trond Myklebust wrote:
> On Wed, 2008-07-16 at 14:48 -0400, J. Bruce Fields wrote:
> > On Wed, Jul 16, 2008 at 04:02:32PM +0800, Wei Yongjun wrote:
> > > J. Bruce Fields wrote:
> > >> On Mon, Jul 14, 2008 at 10:03:01AM +0800, Wei Yongjun wrote:
> > >>   
> > >>> J. Bruce Fields wrote:
> > >>>> So, is the problem occuring because the client is doing a setattr to
> > >>>> modify the size using a sequence id returned from a read delegation?
> > >>>>
> > >>>>         
> > >>> This happend in special case:
> > >>>
> > >>> OPEN (OPEN4_SHARE_ACCESS_BOTH)    --->                                
> > >>>      <---      OPEN Reply OK
> > >>> SETATTR (size=0)                  --->
> > >>> OPEN (OPEN4_SHARE_ACCESS_READ)    --->
> > >>>                                     <---      SETATTR Reply NFSERR_OPENMODE
> > >>>                                     <---      OPEN Reply OK
> > >>>     
> > >>
> > >> Can you see which stateid the SETATTR was done with (in particular,
> > >> where did it come from)?  (You could just send me a link to the raw
> > >> capture if you'd like).
> > >>
> > >>   
> > > The file in this mail is a small tcpdump file of this error, the  
> > > NFSERR_OPENMODE is the NO.298 packet.
> > 
> > Yes, so the stateid used on the setattr represents a read delegation,
> > and was returned in packet 291.  I think that's a client bug.
> 
> You're saying that the client is holding a read delegation while it is
> holding the file open for OPEN4_SHARE_ACCESS_BOTH???

I'm having a hard time with the ietf mail archives, but my memory was
that people agreed that:
	- 3530 wasn't completely clear as to whether a read delegation
	  necessarily conflicted with writes from the client holding the
	  read delegation, and
	- nobody could see a reason why they needed to, so
	- 4.1 explicitly says they don't conflict in this case.

So I think it is a case the client should handle.

> The client may indeed be handling that situation strangely,
> but afaics there would
> definitely appear to be a bug here on the server side.

That said, the Linux server definitely does recall delegations in this
situation.  What version of the server was this seen with?

--b.