From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPErX-0006vp-EQ for qemu-devel@nongnu.org; Thu, 26 Sep 2013 12:56:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPErR-0008Pm-EP for qemu-devel@nongnu.org; Thu, 26 Sep 2013 12:56:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPErR-0008PZ-6S for qemu-devel@nongnu.org; Thu, 26 Sep 2013 12:56:17 -0400 Message-ID: <5244673F.4000203@redhat.com> Date: Thu, 26 Sep 2013 18:56:31 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130926075843.GC24531@stefanha-thinkpad.redhat.com> <5243F661.8000401@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Chunyan Liu Cc: Stefan Hajnoczi , qemu-devel@nongnu.org Il 26/09/2013 12:30, Chunyan Liu ha scritto: > > > > 2013/9/26 Paolo Bonzini > > > 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. > > I don't know if I understand correctly. I think you mentioned > cache=unsafe here, due to the snapshot function? cache=unsafe could > enhance snapshot performance. But btrfs snapshot (btrfs subvolume > snapshot xx xx) and qemu snapshot function are two different levels. > With cow attribute, btrfs snapshot could be achieved very easily. With > nocow attribute, the btrfs snapshot function should be not working on > the file. Does COW preserve the order of writes even after a power loss (i.e. you might lose a write, but then you will always lose all the ones that come after it)? If so, you could run QEMU with "cache=unsafe" and have basically the same data safety guarantees as "cache=writeback" on every other file system. Similarly, you could use "cache.no-flush=true,cache.direct=true" instead of "cache=none". Paolo