On Thu, Nov 20, 2014 at 12:57 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > Hi folks, > > As far as I can tell, receiving a BAD_STATEID on an IO operation on a > delegated stateid when there was a local lock acquired for this IO is > unrecoverable — leads to EIO. Codewise, stateid recovery sees that it > has a local lock and marks it lost and retry of the IO operation > returns the EIO. > > Is the reason for seizing the IO is that if the server for some reason > revoked this stateid then there is no guarantee about the locks and > thus doing any IO. > > This also applies to both 4.0 and 4.1 code as far as I can tell. > > Can somebody confirm or tell me if this is wrong? > Yes. If the server has lost the lock, then the application has lost atomicity for the set of operations that were supposed to be protected by that lock, and this is why we return the EIO. In older kernels we did try to recover the lock, but that can lead to application-visible corruption of data, and so we no longer do that unless you explicitly set the nfs 'recover_lost_locks' module parameter - see Documentation/kernel-parameters.txt. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
