On Wed, Dec 23, 2020 at 4:02 PM Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote: > > On Wed, 2020-12-23 at 22:29 +0800, Qiyu Yan wrote: > > Patrick O'Callaghan <pocallaghan@xxxxxxxxx> 于2020年12月23日周三 下午9:29写道: > > > > > > I have a directory I use to hold a Windows VM disk image > > > (/home/Windows/...), and would like to snapshot it before playing with > > > the QEMU settings. However it's already part of the /home subvolume, so > > > is there a way of splitting it off on its own without having to create > > > a new subvolume and sending the contents over? AFAIK subvolumes can be > > > hierarchical so it would seem like a useful thing to be able to convert > > > a subtree without all the copying, but the man page doesn't seem to > > > address it. > > > > You could create a subvolume, use cp --reflink=always to create a > > reflink, and delete the old directory, this turns a directory into > > subvolume easily without actual copying. But I don't suggest you do > > so, since using snapshot/reflink on VM images will make it > > Copy-on-Write, VM images should be nocow for performance. > > > > But can anyone figure out if creating a reflink then removing old > > references before any write to the file happens turns on CoW for the > > file? I am not sure. But writing after snapshot definitely turns on > > CoW. > > So, if I understand correctly, I can't in fact snapshot a VM without > incurring a COW penalty, independently of how I do it? Yep. Whether Btrfs snapshot, reflink copy on either Btrfs or XFS, or LVM thinp snapshot, or qcow2 snapshot/backing file, there is COW. There's COW because the snapshot makes the data you've snapshot shared. You've got two copies pointing to the same data blocks, i.e. shared blocks or shared extents. Neither file exclusively owns those blocks. Therefore any write to any block in either file *must* be COW. Another way to consider copy on write is "no overwrites". Some folks who haven't suffered these giant text walls of mine by now, might like some animated pictures :D https://github.com/knorrie/btrfs-heatmap You can create your own too. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx