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
Thanks Chris, nice explanation
_______________________________________________ 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
