> If you are saying that we're not making it clear enough that "you > ignore these rules at your peril" then, fair enough, I'm sure Chuck > would be able to add a line to the faq stating just that. Yes, that's basically what I'm saying. I doubt many end users of NFS realize that, given default mount options on modern Linux distributions, simply catting a file that may have just been updated on another system can result in reading back extra bytes that don't exist in the file. I guess my main point is the notion of reading "stale" data vs reading "corrupt" data from the cache. > 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. I was just asking if such a thing existed. It sounds like it doesn't. I don't expect you to produce one. I, for one, simply was not aware that close-to-open cache consistency required that if a file is open for writing on one client that it MUST NOT be read by other clients at the same time (unless you potentially want to read corrupt data). Thanks for taking the time to discuss and clarify, its much appreciated. -- 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
