On Sun, Dec 6, 2020 at 3:54 PM Sergio Belkin <sebelk@xxxxxxxxx> wrote: > > Hi, > Let's say that I have 2 subvolumes for both / and /home. What happen with a snapshot of /home if I run before : > chattr +C /home/jdoe/VMs ? If /home/jdoe/VMs is a directory, then it and its contents are included in the snapshot. And it means nodatacow extents have become shared extents. Writes to shared extents are always cow, even if marked as nocow. So the initial VM "overwrite" to a shared extent will be cow to a new extent that is exclusive, not shared. Subsequent writes to that same exclusive extent will be nocow, i.e. an overwrite. This same principle applies to reflink copies of any file, whether on Btrfs or XFS. A reflink copy also causes extents to become shared extents. My suggestion is to put the VM images in their own subvolume. i.e. from ~/ just do: btrfs sub create VMs Since Btrfs snapshots are not recursive [1] and instead stop at subvolume boundaries, a snapshot of ~/ will not snapshot ~/VMs. [1] https://github.com/kdave/btrfs-progs/tree/master/libbtrfsutil libbtrfsutil provies a C API and python bindings making it possible to do recursive snapshot creation and deletion; but this is not exposed in the user space tools for a number of reasons, mainly it's potentially confusing and risky since btrfs subvolumes and snapshots can be created anywhere without any meaningful limits beyond what the user institutes. Another advantage of libbtrfsutil is it provides an _fd variant of subvolume/snapshot creation and deletion, meaning there doesn't need to be a "line of sight" path to the source or destination via the mounted file system. Ergo, in effect creating "hidden" subvolumes and snapshots; "hidden" as in they're not in the normal mounted file system path. A user can of course always mount the top-level of the file system and see all such subvolumes. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
