From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54672 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9IBV-0006oL-AY for Qemu-devel@nongnu.org; Fri, 22 Oct 2010 10:01:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9IBT-0007ap-SP for Qemu-devel@nongnu.org; Fri, 22 Oct 2010 10:01:29 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:61911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9IBT-0007ai-Pj for Qemu-devel@nongnu.org; Fri, 22 Oct 2010 10:01:27 -0400 Received: by gxk1 with SMTP id 1so681937gxk.4 for ; Fri, 22 Oct 2010 07:01:27 -0700 (PDT) Message-ID: <4CC1993F.1090201@codemonkey.ws> Date: Fri, 22 Oct 2010 09:01:35 -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> <4CC18A89.1060802@codemonkey.ws> <4CC19322.7050205@redhat.com> <4CC1956C.9080008@codemonkey.ws> <4CC19855.6050801@redhat.com> In-Reply-To: <4CC19855.6050801@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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 08:57 AM, Kevin Wolf wrote: > Am 22.10.2010 15:45, schrieb Anthony Liguori: > >>>> 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. >>>> >>>> >>> I don't think that's right. O_SYNC should guarantee that the volatile >>> disk cache is flushed. >>> >>> >> If your filesystem does the right thing which an awful lot of them don't >> today. >> > The list of really relevant filesystems is rather short, though. > > >>>> Likewise, if you mount your filesystem with barrier=0, QEMU is unsafe. >>>> >>>> >>> Yeah, if you do something equivalent to cache=unsafe on a lower layer, >>> then qemu can't do much about it. Maybe you can apply the same argument >>> to NBD, even though it's unsafe by default. >>> >>> >>> >>>> 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. >>>> >>>> >>> docs/block-protocols.txt? >>> >>> >> Maybe docs/block/.txt? Would be a good home for the qed spec too. >> > I think spec and documentation for users should be kept separate. I > thought that's the reason why docs/specs/ exists. > > And if you exclude specs, I'm not sure if there's a lot left to say for > each format. Having ten files under docs/block/ which consist of two > lines each would be ridiculous. If contrary to my expectations we > actually do have content for it, docs/block/.txt works for me as well. > Okay, sounds reasonable. Regards, Anthony Liguori > Kevin >