> -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Brock Noland > Sent: Tuesday, October 23, 2012 8:08 PM > To: linux-nfs@xxxxxxxxxxxxxxx > Subject: readdir from Linux NFS4 client when cookieverf is no longer valid > > Hello, > > It is my first message to this list, so please understand I that I might be in the > wrong place or be wrong altogether. In my spare time I am implementing a > NFS Proxy for the Hadoop Distributed File System: > https://github.com/brockn/hdfs-nfs-proxy The scenario is as follows, two > clients RHEL 6.3 and 5.8: > > Client 1) Creating and deleting files in a directory Client 2) Listing the files in > that directory with a wildcard: foo* > > Eventually client 1 creates a file while client 2 is listing the directory. > > Regarding readdir from a NFS4 client, based on RFC 3530 it is my > understanding that if the cookie verifier is invalid, I should return > NFS4ERR_NOT_SAME. I believe that because of this statement "If the server > determines that the cookieverf is no longer valid for the directory, the error > NFS4ERR_NOT_SAME must be returned." In my case, I am using the number > of entries in the directory as the cookieverf. > Based on the statement above, it was my belief that the client should then > re-read the directory. This discussion comes up pretty much every time someone writes a new NFS server and/or filesystem. The thing that neither RFC1813, RFC3530, or RFC5661 have done is come up with sane semantics for how a NFS client is supposed to recover from the above scenario. What do I do with things like telldir()/seekdir() cookies? How do I recover my 'current position' in the readdir() stream? IOW: how do I fake up POSIX semantics to the applications? Until the recovery question is answered, the Linux client will continue to ignore the whole "cookie verifier" junk... Trond -- 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
