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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux