[linux-cifs-client] cifs_fsync implementation does not trigger SMB_COM_FLUSH

Horst Reiterer horst.reiterer at gmail.com
Mon Feb 9 22:31:22 GMT 2009


Hi,

I've been using the now obsolete client implementation smbfs for quite
some time and relied on the fact that an fsync system call actually
tiggered an SMB_COM_FLUSH to guarantee that all volatile data is
written to stable storage on the server side, provided the server
chooses to honor the request (which, to my knowledge, is true for
Windows and Samba with 'strict sync' enabled).
The new implementation - cifs - does not seem to send SMB_COM_FLUSH
anymore and, as far as I understand the code, merely flushes client
buffers to send any outstanding data to the server. Consequently,
migrating from smbfs to cifs breaks applications that rely on previous
fsync semantics that came closer to those of local filesystems.

Why was the explicit SMB_COM_FLUSH dropped in the new implementation?
Would you accept a patch that reintroduces SMB_COM_FLUSH in the
implementation of cifs_fsync? If you cannot change the current
cifs_flush semantics at this point, how about a mount option (along
the lines of strict sync that enables SMB_COM_FLUSH for explicit fsync
calls)?

Both, the original smbfs implementation and current NFS client and
server implementations (depending on the set of options chosen) are
eligible for use with applications relying on an fsync call to be
forwarded to the file server to ensure that data is written to stable
storage. I personally can't see any reason for not doing the same in
cifs (as mentioned, maybe as part of an option that is off by
default). A quick and dirty modification of the current code base to
enable SMB_COM_FLUSH worked as expected, IMHO that should really
become part of mainline cifs though.

Thanks!

Best regards,

Horst.


More information about the linux-cifs-client mailing list