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: Chunyan Liu
Subject: Re: [Qemu-devel] qemu-img create: set "nocow" flag to solve performance issue on btrfs
Date: Thu, 26 Sep 2013 18:30:47 +0800




2013/9/26 Paolo Bonzini <address@hidden>
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.
 
2) Does ZFS have the same problem?  In other words, could this just be
considered a btrfs bug?

I think the performance issue is due to the COW ifself. With COW, there are more read/write IO(s) when first writing a place, so random small write on a large file would get bad performance. But I don't know how ZFS is affected. Perhaps it degrades not so much?
 
Paolo



reply via email to

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