[linux-cifs-client] close-to-open cache consistency and cifs

[Jeff Layton]

On Fri, 19 Dec 2008 23:14:56 -0600
Steven French <sfrench at us.ibm.com> wrote:

> It is not obvious to me why posix locking would/should have any relation 
> to clean/dirty pages.   Other clients don't use posix locks for this, so 
> the only chance we would have to do this safely would be in an all Linux 
> environment (perhaps optional).   If NFS uses posix locks for this, today 
> we are more conservative than nfs, since we flush non-cacheable files on 
> every write (and NFSv3 can't do safe caching).
> 

Often people try to use networked filesystems as shared storage for
applications -- i.e. they want to be able to do writes to a file and
have the other readers see those changes.

Obviously, you can do this by opening with O_SYNC or mounting with
"sync", or making sure that you fsync at the right time, but how do you
ensure that the client isn't relying on cached data once it grabs the
lock? You have to revalidate the file when you take the lock.

Given the reason that most applications use locking in the first place,
it makes sense to make sure that the client is working with up to date
file data when taking a lock and that the server has an up to date copy
when releasing the lock. If we have an oplock of course then there's no
need for any of that.

This is simply an attempt to tighten up cache consistency when several
clients are holding open the same file, doing I/O to it, and using
posix locks to serialize access.

-- 
Jeff Layton <jlayton at redhat.com>