On Sun, Feb 22, 2009 at 7:36 PM, Trond Myklebust
<trond.myklebust@xxxxxxxxxx> wrote:
> On Sun, 2009-02-22 at 19:23 -0600, Steve French wrote:
>> CIFS implementation of fsync flushed the cache on the client
>> (filemap_fdatawait etc.), but did not send the SMB FLUSH operation to
>> the server requesting that the server write all data for this inode to
>> the metal on the server side (until now). Some servers have a range
>> of configuration options to handle dumb applications that sync too
>> often (which is common on windows) or strange workloads e.g. "strict
>> sync = no" to "sync always" (in which the server issues fsync locally
>> after after SMB write is processed).
>>
>> The suggestion was to add a mount option on the cifs client
>> ("nostrictsync") to allow it to optionally just flush all of the
>> writes (and wait for write responses) but not force the server to sync
>> them to the metal (as a strict interpretation of sync would require).
>
> In NFS we always enforce the strict rule that we COMMIT on close(), but
> I do know that a lot of *BSD based implementations skip that step. As
> long as the server doesn't reboot, and/or the file is not shared with
> other clients, then that is a reasonable strategy.
> That said, I do also agree that you might want to enforce stricter rules
> by default, and then allow admins to relax them using a mount option.
>
> Speaking of cache consistency, what about the ability to flush caches?
> Is there any interest within the CIFS community to allow user
> applications to invalidate the page cache and/or attribute caches when
> no delegation/oplock is held and the app knows that a file or directory
> may have changed on the server? It is an issue that keeps getting raised
> on the NFS side, but that we haven't addressed yet.
That is an interesting question. In cifs we already read through to
the server (rather than out of the page cache) if no read oplock is
held so I doubt that it would make much difference if we knew that the
server copy had changed (we would still read through to the server).
For the attribute cache it might make a difference though since we
cache file attributes (time stamps, mode etc.) for 1 second.
SMB/CIFS (and SMB2) protocol has a fairly useful set of protocol
operations (that we don't use) for file change notification (and
directory change notification) that we could use to do "loose cache
consistency" if someone wanted that (we can get notified by the server
when a non-oplocked inode is modified, or a directory is modified, so
could catch server side updates fairly quickly even when a file is not
strictly cacheable).
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
