On Wed, Feb 25, 2015 at 12:04 PM, Chris Perl <cperl@xxxxxxxxxxxxxx> wrote: >> That's expected behaviour, yes. NFS close-to-open cache consistency >> semantics do not allow for concurrent access while the file is being >> updated. > > Can you elaborate on that a bit? > > My rough understanding of close-to-open cache consistency is basically > that a clients changes are not guaranteed to be on the server until a > close(2) and that a client is only guaranteed to check for updates on > open(2). > > I can therefore see why one client reading while another is appending > could result in stale data being read from the cache (and indeed, this > is the reason the test program I provided continually open and closes > the file, seeking as necessary). But I'm having a hard time seeing > why close-to-open cache consistency allows for returning data from the > cache that never existed in the file. So imagine 2 WRITE calls that are being sent to an initially empty file. One WRITE call is for offset 0, and length 4096 bytes. The second call is for offset 4096 and length 4096 bytes. Imagine now that the first WRITE gets delayed (either because the page cache isn't flushing that part of the file yet or because it gets re-ordered in the RPC layer or on the server), and the second WRITE is received and processed by the server first. Once the delayed WRITE is processed there will be data at offset 0, but until that happens, anyone reading the file on the server will see a hole of length 4096 bytes. This kind of issue is why close-to-open cache consistency relies on only one client accessing the file on the server when it is open for writing. -- 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
