> Never used LXD, but LXC does not have layers per-se.
It's kind of a similar situation in LXD, where that sort of functionality being available depends on the storage backend/driver in use, for example LVM thin provisioning, various options via ZFS, or btrfs like you mentioned.
Hm yeah, in some sense I like the things to be more orthogonal, i.e. container images vs. the file system
On the other hand I think storage and networking should be more unified, and the differential compression and caching you get from layers is important
I suspect that doing the layers at the logical level (files) , like overlayfs, rather than the physical level (blocks) is also better for containers, but I'd be interested to read any comparisons
It depends on the workload. Copy-up is more expensive than snapshots. If it's ext4+overlayfs, then copy-up is really expensive (full file copy), whereas if it's btrfs or XFS then it's reflink copies. Much more efficient. But btrfs snapshots in effect are instant reflink copies. But then overlayfs has the benefit of shared pages.
Also, at least Btrfs snapshots are more logical, like files; than physical, like blocks. Whereas LVM snapshots are separate (logical) block devices, Btrfs snapshots are file b-trees on the same file system.
Maybe the overlay2 graph driver (the driver used in Docker or Podman to interface with the kernel) is getting more usage and thus maturing more quickly, compared to the btrfs graph driver? I think upstream Docker/Moby are defaulting to the btrfs graph driver if /var/lib/docker is on Btrfs. Meanwhile on Fedora where Btrfs is the default for desktops, and Cloud edition, Podman defaults to overlay2 graph driver no matter the underlying file system.
It's kind of a similar situation in LXD, where that sort of functionality being available depends on the storage backend/driver in use, for example LVM thin provisioning, various options via ZFS, or btrfs like you mentioned.