From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42168 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9HIB-0001qN-Qz for Qemu-devel@nongnu.org; Fri, 22 Oct 2010 09:04:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9HCj-00089x-I6 for Qemu-devel@nongnu.org; Fri, 22 Oct 2010 08:58:42 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:53570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9HCj-00089t-Dq for Qemu-devel@nongnu.org; Fri, 22 Oct 2010 08:58:41 -0400 Received: by iwn36 with SMTP id 36so1012613iwn.4 for ; Fri, 22 Oct 2010 05:58:41 -0700 (PDT) Message-ID: <4CC18A89.1060802@codemonkey.ws> Date: Fri, 22 Oct 2010 07:58:49 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] bdrv_flush for qemu block drivers nbd, rbd and sheepdog References: <4CC04920.8040902@redhat.com> <4CC05744.1060204@codemonkey.ws> <1287689572.2724.0.camel@Quad> <4CC14B60.7090900@redhat.com> In-Reply-To: <4CC14B60.7090900@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Laurent Vivier , Qemu-devel@nongnu.org On 10/22/2010 03:29 AM, Kevin Wolf wrote: >> I agree. >> > Of course, as Laurent said a while ago, there is no specification for > NBD, so it's hard to say what the intended semantics is. > > However, I did have a look at the nbdserver code and it looks as if it > implements something similar to writethrough (namely fsync after each > write) only if configured this way on the server side. qemu-nbd defaults > to writethrough, but can be configured to use cache=none. So with either > server qemu as a client can't tell whether the data is safe on disk or not. > > In my book this is a strong argument for refusing to open nbd > connections with anything but cache=unsafe. > On a physical system, if you don't have a battery backed disk and you enable the WC on your disk, then even with cache=writethrough we're unsafe. Likewise, if you mount your filesystem with barrier=0, QEMU is unsafe. QEMU can't guarantee safety. The underlying storage needs to be configured correctly. As long as we're not introducing caching within QEMU, I don't think we should assume we're unsafe. Do we have any place where we can add docs on a per-block format basis? It would be good to at least mention for each block device how the backing storage needed to be configured for safety. Regards, Anthony Liguori > Kevin >