On Thu, Feb 26, 2015 at 11:00 AM, Chris Perl <cperl@xxxxxxxxxxxxxx> wrote: >> It is up to you to ensure that you don't set up such a situation, just >> like it is also your responsibility to ensure that you don't run 2 >> applications that do read-modify-writes to the same file on a regular >> POSIX filesystem. >> >> This is a rule that has worked just fine for the NFS community for more >> than 30 years. It isn't anything new that we're only adding to Linux. > > I'm not trying to be annoying and hope I'm not coming across as such. > > Given that I've used NFS for many years being blissfully unaware of > the close-to-open cache consistency requirement you've described (it > seems to work most of the time!), I'm generally curious if there are > other such rules I must follow or if the one we've been discussing is > the only such rule. The only other things that I can think of are: 1) Attributes are generally not immediately updated on clients. Even if you specify 'noac', there is no locking that can ensure size changes, for instance, are reflected well enough on the client to ensure perfect O_APPEND semantics. 2) Readdir results are unreliable when the directory is being updated on the server or on other clients. You should still be able to depend on O_EXCL file create semantics, though. 3) the lack of flock() type locks. We have to emulate them using byte range locks, which means that under NFS the fcntl() and flock() locks can and will conflict with one another. 4) file notifications generally do not work well, since there is no protocol support for that either -- 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
