On Mar 2, 2015, at 3:58 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Mon, Mar 02, 2015 at 10:57:43AM -0500, Chuck Lever wrote: >> Hi Chris! >> >> Still in the context of deciding what should go in the FAQ, my >> comments are below. >> >> >> On Mar 2, 2015, at 10:19 AM, Chris Perl <cperl@xxxxxxxxxxxxxx> wrote: >> >>>> I’m in favor of staying more hand-wavy. Otherwise you will end up >>>> making promises you don’t intend to keep ;-) >>> >>> FWIW, I'm in favor of at least some specifics. Something stating that >>> the results of reading from a file while another client holds it open >>> for write are undefined (point 3 of what was already proposed). >> >> The language has to be very careful. >> >> Opens for write are used frequently and by themselves do not cause >> any damage. Corruption risk increases when actual writes occur, >> followed by reads of the same file on other clients, without a >> close and re-open. >> >> Also, any published statement about this could lock us into a >> particular behavior. That makes it harder to improve or change >> (say, to address a bug) in the future. >> >> Specifics can be discussed on the mailing list on a case-by-case >> basis. The specifics depend on a bunch of things, for example: >> >> - which clients are in play >> - which NFS version is in use (delegations and open state) >> - whether reading and writing is in the same byte range >> - whether the file size is changing >> - whether O_DIRECT and mapped files are in use > > These are cases we'd only need to go into if we wanted to give > *stronger* gaurantees than "all bets are off when you don't serialize > with write opens", yes? > And, sure, that would be interesting, but I think Chris is just asking > for a clearer statement of that basic requirement. 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? > He's far from the first to assume that the results you'd get from > overlapping opens would be out of date but still reasonable in some > sense, and the FAQ could use a stronger statement that that's not the > case. No disagreement there. I’m just trying to figure out the right level of detail. > --b. > >> >> And so on. There could also be real bugs, which would become >> apparent after discussion. >> >> A general (and more explicit) warning about write sharing is >> appropriate to add. I feel it would be difficult to get the >> specifics right. >> >> I could add something to A8 that says “Detailed questions can be >> directed to linux-nfs@xxxxxxxxxxxxxxx.” Do you feel you got a good >> answer from the mailing list? >> >> -- >> Chuck Lever >> chuck[dot]lever[at]oracle[dot]com >> >> -- 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
