It is EMC server. The server returns the delegation to the OPEN CLAIM_DELEGATE_CUR operation. At this point the delegation is still valid. This is far before the DELEGRETURN; so this doesn't explain why the delegation is used in SETATTR (frame 5596) after the DELEGRETURN (frame 5589, reply in 5592). Returning a delegation to OPEN CLAIM_DELEGATE_CUR is probably useless, as the client already has this delegation. But, I don't think that it is illegal. If this creates the confusion, we can avoid returning the delegation in this case. -----Original Message----- From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of J. Bruce Fields Sent: mardi 1 mars 2011 05:10 To: Trond Myklebust Cc: Jim Rees; Benny Halevy; linux-nfs@xxxxxxxxxxxxxxx; peter honeyman Subject: Re: [PATCH] zero out delegation in the inode after it has been returned On Mon, Feb 28, 2011 at 07:00:33PM -0500, Trond Myklebust wrote: > On Mon, 2011-02-28 at 18:22 -0500, Jim Rees wrote: > > Trond Myklebust wrote: > > > > The procedure for returning delegations is supposed to work as follows: > > > > 1. Remove the nfsi->delegation so that it is no longer visible to > > new open() requests > > 2. write back any dirty data to the server > > 3. Reclaim any locks > > 4. Reclaim any open stateids (using CLAIM_DELEGATE_CUR) > > 5. delegreturn > > > > While there may indeed be the odd READ or WRITE that races between 4. > > and 5., so that the server receives the delegation stateid after the > > delegreturn, that shouldn't matter: the server returns an error, and the > > client should retry using the new open stateid. > > > > What is failing to work correctly here? > > > > That helps, thanks. I'll see if I can figure out what's going wrong. > > > > At the server, I see a delegreturn followed by a setattr using the returned > > stateid. The server returns BAD_STATEID. I'll look to see if the client > > then retries. > > > > At the client, I see a non-null nfsi->delegation after the delgreturn, and > > the application gets a EIO. > > That's because your server is confusing the hell out of us all by giving > out a delegation as part of the reply (in frame 5328) to the > OPEN(CLAIM_DELEGATE_CUR) in frame 5325. > > IOW: the client is in the process of returning the delegation, and asks > to trade in the delegation stateid into an open stateid, then the server > replies with an open stateid, and the delegation stateid... Which server is this, Jim? (I checked the Linux server quickly and it doesn't look like it should do this....) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
