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... Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
