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. Thank you. -- 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
