All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.