Just to quickly answer the earlier question about whether I have received a good answer from this list: Yes, I have, and I appreciate all the time and discussion spent helping me understand what I've been seeing. > I read Chris’s e-mail as a request for more detail in the answer > I proposed before. Maybe I’m wrong. > > Is this not sufficient: > > “Because NFS is not a cluster or “single system image” filesystem, > applications must provide proper serialization of reads and writes > among multiple clients to ensure correct application behavior and > prevent corruption of file data. The close-to-open mechanism is not > adequate in the presence of concurrent opens for write when multiple > clients are involved.” > > Perhaps the “presence of concurrent opens for write” should be > replaced with “presence of concurrent writes.” But what else needs > to be said? I'm trying to decide if, having read the above in the FAQ, it would have been obvious to me that what I was seeing was expected. I don't know that it would have been. That paragraph seems to impart to me the idea that if you don't synchronize your readers and writers you might get weird results, much like a local file system. However, I thought the way in which my updates were happening made this ok, as I was only ever appending data to a given file. I guess I was hoping for something more along the lines of (this would be meant to be inserted after paragraph 6 of A8 in the FAQ): Furthermore, in the presence of multiple clients, at least one of which is writing to a given file, close-to-open cache consistency makes no guarantee's about the data that might be returned from the cache on a client issuing reads concurrent with those writes. It may return stale data or it may return incorrect data. -- 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
