qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Chunyan Liu <cyliu@suse.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu-img create: set "nocow" flag to solve performance issue on btrfs
Date: Thu, 26 Sep 2013 18:56:31 +0200	[thread overview]
Message-ID: <5244673F.4000203@redhat.com> (raw)
In-Reply-To: <CAERYnoYJVeGV+eMyEio-e1zn46j5r+JKsLAD9MsQdwtxO0bxxA@mail.gmail.com>

Il 26/09/2013 12:30, Chunyan Liu ha scritto:
> 
> 
> 
> 2013/9/26 Paolo Bonzini <pbonzini@redhat.com <mailto:pbonzini@redhat.com>>
> 
>     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

  reply	other threads:[~2013-09-26 16:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25  6:38 [Qemu-devel] qemu-img create: set "nocow" flag to solve performance issue on btrfs Chunyan Liu
2013-09-26  7:58 ` Stefan Hajnoczi
2013-09-26  8:54   ` Paolo Bonzini
2013-09-26 10:30     ` Chunyan Liu
2013-09-26 16:56       ` Paolo Bonzini [this message]
2013-09-27  8:58         ` Chun Yan Liu
2013-09-27  9:02           ` Paolo Bonzini
2013-09-26  9:04   ` Chunyan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5244673F.4000203@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=cyliu@suse.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).