qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block: Add support for Secure Shell (ssh) block


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] block: Add support for Secure Shell (ssh) block device.
Date: Tue, 26 Mar 2013 10:37:49 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]