From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UK93n-0006ay-B8 for qemu-devel@nongnu.org; Mon, 25 Mar 2013 11:11:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UK93l-0004l1-CA for qemu-devel@nongnu.org; Mon, 25 Mar 2013 11:11:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UK93l-0004kt-3v for qemu-devel@nongnu.org; Mon, 25 Mar 2013 11:11:41 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2PFBeSL023623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Mar 2013 11:11:40 -0400 Date: Mon, 25 Mar 2013 15:11:37 +0000 From: "Richard W.M. Jones" Message-ID: <20130325151137.GN1504@rhmail.home.annexia.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130325143622.GA24866@dhcp-200-207.str.redhat.com> 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: Kevin Wolf Cc: qemu-devel@nongnu.org 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). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW