On Mon, 30 Apr 2012 10:11:43 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > There is a related question of how deferring writes slightly (e.g. to > buffer a full page or a full smb buffer) could corrupt data? > You're returning from write(2) without actually sending it to the backing store, but a read(2) will go to that backing store. So, applications that expect the results of that write to be visible to other clients (or even on the same client) won't see it. > AFAIK - there isn't an ordering guarantee in posix when writes from > two different applications overlap (thus the need for byte range locks > or other synchronization mechanisms, or flush/fsync). > Correct, there isn't, but even locking doesn't really help with cifs.ko since it doesn't treat locks as cache coherency points like the nfs client does. Even if it did though, the NFS cache coherency model is not necessarily something we want to emulate. It's pretty fragile itself. Coarse-grained timestamps on the underlying fs can easily break it for instance. To compound the problem, windows servers tend to be quite lazy about mtime updates. So even if you do proper locking, there's no guarantee that the "loose" cache coherency algorithm in cifs.ko will detect that the file has changed. Another client might do some writes but the mtime doesn't necessarily change as a result. I'm certainly aware that this might slow down performance in some cases. Those people however can always switch to the less-safe cache=loose if they wish. By default however, we should attempt to follow the letter of the protocol as best we can... -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
