[libvirt] [PATCH] add --nocow option to vol-create and vol-clone

[Chunyan Liu]

2013/12/6 Chunyan Liu <cyliu at suse.com>

>
>
>
> 2013/12/5 Daniel P. Berrange <berrange at redhat.com>
>
> On Thu, Dec 05, 2013 at 06:35:12PM +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 is to turn off COW attributes on VM files (since having
>> copy on
>> > write for this kind of data is not useful).
>> >
>> > According to 'chattr' manpage, NOCOW could be set to new or empty file
>> only on
>> > btrfs, so this patch tries to add a --nocow option to vol-create
>> functions and
>> > vol-clone function, so that users could have a chance to set NOCOW to a
>> new
>> > volume if that happens to create on a btrfs like file system.
>>
>> What effect / impact does setting this flag have from a functional
>> POV ?
>
>
> It implies nodatasum as well. But COW may still happen if a snapshot is
> taken.
>
> Following is quoted from:
>  https://btrfs.wiki.kernel.org/index.php/FAQ
>
>  Can copy-on-write be turned off for data blocks?
>
>  Yes, there are several ways how to do that.
>
>  Disable it by mounting with nodatacow. This implies nodatasum as well.
> COW may
> still happen if a snapshot is taken. However COW will still be maintained
> for
> existing files, because the COW status can be modified only for empty or
> newly
> created files.
>
>  For an empty file, add the NOCOW file attribute (use chattr utility with
> +C),
>  or you create a new file in a directory with the NOCOW attribute set
> (then the
>  new file will inherit this attribute). Now copy the original data into
> the
>  pre-created file, delete original and rename back.
>
>  Why would we not just unconditonally enable it on btrfs so
>> it was fast "out of the box" ?
>
>
>  COW is default feature of Btrfs. There are many advantages with COW
> mechanism.
>  Other uses may want the COW advantages at the same time we set NOCOW to a
> VM
>  image.
>
>  But in pool-create and vol-create case, it seems the whole pool is used
>  to hold VM images, so maybe we could just disable COW in pool side. Then
> all
>  vol created in it will be NOCOW. That means, in pool-start phase, if
> checking
>  fs format is 'btrfs', add '-o nodatacow' option to 'mount' command. That
> still need some
>  change in libvirt code. How do you think about this way?
>

Daniel, about the nocow issue, could we do *mount* -o *nodatacow* in
pool-start if checked
that fs format is btrfs?

Chunyan


>
> Thanks,
> Chunyan
>
>
>> I'm loathe to add a btrfs-specific
>> flag to our public API.
>>
>> Daniel
>> --
>> |: http://berrange.com      -o-
>> http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-
>> http://virt-manager.org :|
>> |: http://autobuild.org       -o-
>> http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-
>> http://live.gnome.org/gtk-vnc :|
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131210/04d87439/attachment-0001.htm>