On Apr 25, 2014, at 2:01 AM, J. Bruce Fields wrote: > On Fri, Apr 18, 2014 at 09:54:28AM -0700, Glenn Skinner wrote: >> See comments in line. >> >> On Apr 18, 2014, at 2:04 AM, J. Bruce Fields wrote: >> >>> Agreed that this sounds like a bug. >> >> Thanks for looking at this. >> >>> a8a7c6776f8d74780348bef639581421d85a4376 "nfsd: Don't return >>> NFS4ERR_STALE_STATEID for NFSv4.1+", now in v3.15-rc1, prevents the >>> stale_stateid return. What are the symptoms on your client? If this >>> fixes a practical issue for users then we should probably get that >>> backported to stable. >> >> Let me ask a question in turn. Does your fixed server return NFS4ERR_BAD_STATEID in circumstances where pre-fix it would return NFS4ERR_STALE_STATEID? > > Right. Makes sense. Just wanted to confirm. >> I ask because (in production versions of ESX, which don't have assertions enabled) we return a lock lost error upward for the former, but an IO error for the latter. This difference has consequences for higher-level software, such as our FT (fault tolerance) software feature where it will affect decisions on how quickly to fail over to another ESX instance. >> >> For development versions of ESX encountering NFS4ERR_STALE_STATEID triggers an assertion failure, which forces the instance in question to crash. That has definite practical consequences for our internal development and testing organizations. > > So, our "fixed server" behavior is an improvement as far as your client > is concerned? Yes, it is. Thanks for fixing this bug. -- Glenn -- 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
