qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu-img create: set "nocow" flag to solve performance


From: Paolo Bonzini
Subject: Re: [Qemu-devel] qemu-img create: set "nocow" flag to solve performance issue on btrfs
Date: Thu, 26 Sep 2013 10:54:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]