On Mon, Mar 25, 2013 at 03:11:37PM +0000, Richard W.M. Jones wrote: > On Mon, Mar 25, 2013 at 03:36:22PM +0100, Kevin Wolf wrote: > > You don't have a bdrv_co_flush_to_disk, what does this mean? Is every > > write immediately flushed to the disk, is the driver unsafe by design, > > or is this just a missing implementation detail? > > Initially there is no .bdrv_co_flush_to_disk because this patch is > just a proof of concept. > > However it does seem likely that a true flush-to-disk operation is not > possible with sftp. Assuming this is supposed to guarantee that the > bits have been committed to disk, I don't see anything in the sftp > protocol that supports that guarantee. It seems to be left up to the > implementation to do whatever it wants. > > Here's the protocol v3 as implemented by OpenSSH: > > http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02 > > and here's the latest version v6 (not implemented by anyone AFAIK): > > http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 > > if you think you can see anything that I've missed ... > > Also I grepped over the source of OpenSSH and there is no call to > sync(2), fsync(2) or fdatasync(2).
I looked at OpenSSH sftp-server.c to see if open, close, or write do anything special. They don't. There's also no 'sync' command in the SFTP protocol. So unless the underlying filesystem is mounted -o sync, there is no guarantee that data is safely on disk. Stefan