2013/12/6 Chunyan Liu <[email protected]> > > > > 2013/12/5 Daniel P. Berrange <[email protected]> > > 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 :| >> >> >
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
