>> Ok, thanks for helping me understand this a little more clearly. For >> my own edification, is there somewhere I can find the details where >> these things are spelled out (or is it just somewhere in rfc1813 that >> I haven't seen)? > > There is a short description here: > http://nfs.sourceforge.net/#faq_a8 Yes, thanks. I had come across that when trying to do a little research after your initial reply. However, I was hoping for something with a little more detail. For example, you said earlier that "the close-to-open cache consistency model is clear ...", which implied to me that there was a more formal description somewhere outlining the semantics and constraints. Or is it just more of an implementation detail? Also, reading that FAQ entry seems to reinforce my original notion that a client reading a file that is being updated might get stale data returned from its cache, but shouldn't get corrupt data returned from its cache. Perhaps the FAQ entry should be updated to explicitly note that corrupt data can be returned? FWIW, I realize that the use case I've given as a reproducer isn't supported and isn't supposed to work. I accept that and that is fine. However, we do run into this problem in "everyday types of file sharing" (to quote that FAQ). Sometimes (not very often, but enough that its annoying), someone will cat a file that is already in their clients page cache, and it happens to be at just the wrong time, resulting in corrupt data being read. -- 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
