From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKQKJ-00035C-5W for qemu-devel@nongnu.org; Tue, 26 Mar 2013 05:37:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKQKH-0004bn-EQ for qemu-devel@nongnu.org; Tue, 26 Mar 2013 05:37:55 -0400 Received: from mail-bk0-x22e.google.com ([2a00:1450:4008:c01::22e]:33217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKQKH-0004bd-5t for qemu-devel@nongnu.org; Tue, 26 Mar 2013 05:37:53 -0400 Received: by mail-bk0-f46.google.com with SMTP id je9so1191964bkc.5 for ; Tue, 26 Mar 2013 02:37:52 -0700 (PDT) Date: Tue, 26 Mar 2013 10:37:49 +0100 From: Stefan Hajnoczi Message-ID: <20130326093749.GB24025@stefanha-thinkpad.redhat.com> References: <1363873138-30568-1-git-send-email-rjones@redhat.com> <1363873138-30568-2-git-send-email-rjones@redhat.com> <20130325143622.GA24866@dhcp-200-207.str.redhat.com> <20130325151137.GN1504@rhmail.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130325151137.GN1504@rhmail.home.annexia.org> Subject: Re: [Qemu-devel] [PATCH] block: Add support for Secure Shell (ssh) block device. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Kevin Wolf , qemu-devel@nongnu.org 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