Chunyan Liu wrote: > > 2013/12/5 Daniel P. Berrange <berrange@xxxxxxxxxx > <mailto:berrange@xxxxxxxxxx>> > > 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, Any thoughts on Chunyan's suggestion? It seems mounting a btrfs pool with nodatacow provides out-of-the-box performance improvement, but doesn't later preclude creating/using COW volumes from the pool. Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list