From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP7Le-0004D8-25 for qemu-devel@nongnu.org; Thu, 26 Sep 2013 04:55:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VP7LU-0003hL-6R for qemu-devel@nongnu.org; Thu, 26 Sep 2013 04:54:58 -0400 Received: from mail-qc0-x22b.google.com ([2607:f8b0:400d:c01::22b]:44608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP7LU-0003h2-28 for qemu-devel@nongnu.org; Thu, 26 Sep 2013 04:54:48 -0400 Received: by mail-qc0-f171.google.com with SMTP id x19so541655qcw.16 for ; Thu, 26 Sep 2013 01:54:47 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5243F661.8000401@redhat.com> Date: Thu, 26 Sep 2013 10:54:57 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130926075843.GC24531@stefanha-thinkpad.redhat.com> In-Reply-To: <20130926075843.GC24531@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-img create: set "nocow" flag to solve performance issue on btrfs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Chunyan Liu , qemu-devel@nongnu.org Il 26/09/2013 09:58, Stefan Hajnoczi ha scritto: > On Wed, Sep 25, 2013 at 02:38:36PM +0800, Chunyan Liu wrote: >> Btrfs has terrible performance when hosting VM images, even more when the >> guest in those VM are also using btrfs as file system. >> One way to mitigate this bad performance would be to turn off COW >> attributes on VM files (since having copy on write for this kind of data is >> not useful). We could improve qemu-img to ensure they flag newly created >> images as "nocow". For those who want to use Copy-on-write (for >> snapshotting, to share snapshots across VM, etc..) could be able to change >> this behaviour by 'chattr', either globally or per VM. > > The full implications of the NOCOW attribute aren't clear to me. Does > it really mean the file cannot be snapshotted? Or is it purely a data > integrity issue where overwriting data in-place puts that data at risk > in case of hardware/power failure? > >> I wonder could we add a patch to improve qemu-img create, to set 'nocow' >> flag by default on newly created images? > > I think that would be fine. It's a ioctl(FS_IOC_SETFLAGS, FS_NOCOW_FL) > call so not even too btrfs-specific. I'm not sure... I have some questions: 1) Does btrfs cow mean that one could run with cache=unsafe, for example? If we create the image with nocow, this would not be true. 2) Does ZFS have the same problem? In other words, could this just be considered a btrfs bug? Paolo