On Fri, May 20, 2016 at 4:43 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > > On 5/20/16, 16:38, "linux-nfs-owner@xxxxxxxxxxxxxxx on behalf of Olga > Kornievskaia" <linux-nfs-owner@xxxxxxxxxxxxxxx on behalf of aglo@xxxxxxxxx> > wrote: > >>Hi folks, >> >>I’m seeing a client behavior that I can’t explain the reason behind >>(i.e. spec) so want to ask for help. >> >>Question #1: Should a reclaim of open state handle BAD_SEQID the same >>way the normal open handles BAD_SEQID (which is: it just retries). I >>can see that during recovery we might not want the recovery to be >>trying forever and that’s why we fail? I don’t see anything in the >>spec that talk about this… >> >>Question #2: Incrementing seqid of open owner. I see that when LOCK >>receives an error BAD_STATEID/ADMIN_REVOKED, sequence isn’t >>incremented and (recovery) OPEN is sent with the same seqid. The code >>explicitly sets seqid unconfirmed. Again, I don’t know where to look >>in the spec for something like this. What happens is that server >>replies back with BAD_SEQID. >> >>So normally, when an open fails with BAD_SEQID the client retries but >>combine it with a LOCK that failed with BAD_STATEID. Then it leads to >>the application failing with “bad file descriptor” because after >>receiving an error for the lock and trying to do open recovery, the >>code doesn’t increment seqid and open fails with BAD_SEQID and we >>don’t retry the open. So now we don’t have a file descriptor and we >>fail the lock. >> > > See: > https://tools.ietf.org/html/rfc7530#section-9.1.7 > > The client MUST advance the sequence number for the CLOSE, LOCK, > LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE operations. This is > true even in the event that the previous operation that used the > sequence number received an error. The only exception to this rule > is if the previous operation received one of the following errors: > NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID, NFS4ERR_BAD_STATEID, > NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR, NFS4ERR_RESOURCE, > NFS4ERR_NOFILEHANDLE, or NFS4ERR_MOVED. > Thanks Trond. > Cheers > Trond > > > Disclaimer > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. -- 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
