On Mar 3, 2015, at 8:29 AM, Chris Perl <cperl@xxxxxxxxxxxxxx> wrote: > 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. That’s exactly the right question to ask. > 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. This works for me. Bruce, Trond, any thoughts? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
