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

[Chun Yan Liu]

>>> On 9/27/2013 at 12:56 AM, in message <address@hidden>, Paolo
Bonzini <address@hidden> wrote: 
> Il 26/09/2013 12:30, Chunyan Liu ha scritto: 
> >  
> >  
> >  
> > 2013/9/26 Paolo Bonzini <address@hidden <mailto: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. 
>  
> 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 
>  
>