[PATCH 0/4] cifs: pave way for change to "strictcache" by default

Jeff Layton jlayton at samba.org
Mon Apr 30 09:45:47 MDT 2012

On Mon, 30 Apr 2012 10:11:43 -0500
Steve French <smfrench at gmail.com> 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

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 at samba.org>

More information about the samba-technical mailing list