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. Cheers Trond ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
