On Thu, 2015-02-26 at 10:22 -0500, Simo Sorce wrote: > On Thu, 2015-02-26 at 09:10 -0500, Chris Perl wrote: > > > However if you are asking us for an extensive list of "this is what I > > > can expect if I ignore these rules", then I don't think you will find > > > much traction. Such a list would be committing us to defining a model > > > for "non-close-to-open" semantics, which isn't of interest to me at > > > least, and I doubt anyone else is interested in committing to > > > maintaining that. > > > > One more point on this. I wasn't really asking for a list of what I > > can expect if I ignore the rules (although I think pointing out that > > reading corrupt data from the cache is worth mentioning), I was asking > > what the rules for close-to-open consistency were so I can follow > > them. I now know one of them is that if a file is open for writing on > > one client then it can't be read on another. Are there others? > > Is this a rule or a bug ? > How does an application know that the file is open elsewhere for > writing ? 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. -- 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
