>>> On 9/27/2013 at 12:56 AM, in message <5244673f.4000...@redhat.com>, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 26/09/2013 12:30, Chunyan Liu ha scritto: > > > > > > > > 2013/9/26 Paolo Bonzini <pbonz...@redhat.com <mailto:pbonz...@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)?
Yes, I think so. COW could make sure at any time its FS tree points to a valid root (has all data in a consistent status), if due to the power loss, write task is not completed, it still points to the older root; if write task is completed, it will points to a new root. No matter in which case, it is a consistent status. > 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. "cache=unsafe" means it never calls fsync() ? If so, it seems to be not proper to use this option to disk image of a running VM. In case someone has run the VM for a very long time and made many changes already on the disk image, but all those are in cache (?) Then due to a power off, all these changes are lost. Although the disk image is still in a consistent data status, but the data is maybe too old. - Chunyan > > Similarly, you could use "cache.no-flush=true,cache.direct=true" instead > of "cache=none". > > Paolo > >