On Sun, Feb 22, 2009 at 4:04 PM, Trond Myklebust
<trond.myklebust@xxxxxxxxxx> wrote:
> On Sun, 2009-02-22 at 15:04 -0600, Steve French wrote:
>> Does the Linux nfs client (or other similar clients) have a mount
>> option to control fsync behavior?
>
> Err??? What's the context here? I suppose that we do have '-onolock'
> which turns off NFSv2/v3 remote locking.
>
> Cheers
> Trond
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).
>> ---------- Forwarded message ----------
>> From: Steve French <smfrench@xxxxxxxxx>
>> Date: Sun, Feb 22, 2009 at 3:03 PM
>> Subject: Re: [PATCH] fs/cifs: send SMB_COM_FLUSH in cifs_fsync
>> To: Horst Reiterer <horst.reiterer@xxxxxxxxx>
>> Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-cifs-client@xxxxxxxxxxxxxxx
>>
>>
>> On Sun, Feb 22, 2009 at 2:50 PM, Horst Reiterer
>> <horst.reiterer@xxxxxxxxx> wrote:
>> > In any case, it's probably a good idea to introduce a mount option. The
>> > new behavior should be enabled by default though, to provide maximum data
>> > consistency.
>>
>> Suggestions on what to call such a new mount option? How about
>> "nostrictfsync" ?
--
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
