zfs backend

[NicholasBHubbard]

No description provided.

[Vultimate1]

Looks good to me! Take as much time as you need to test before merging (I know that sounds obvious).

[NicholasBHubbard]

I have ran into significant problems trying to get zfs to work in Docker on my system. This is due to the fact that Docker containers shares the host system kernel, which on my system is version 5.15.139, but in the Debian repos (our base Docker image is Debian) have a version of zfs for a 6.X kernel.

Due to the fact that yaesm heavily relies on kernel based programs (btrfs, zfs, etc) it may make more sense to switch out test suite over to using virtual-machines instead of containers. This would allow us to avoid kernel incompatibilities as the virtual-machines would be running the correct kernel for the OS, unlike Docker containers.

I am looking into using vagrant which is a tool for creating reproducible virtual-machines. Note that by using virtual-machines instead of Docker, we could also do testing on operating systems other than Linux (such as BSD, Windows, etc).

[NicholasBHubbard]

rebased onto main after merging #25

[NicholasBHubbard]

rebased onto main after merging #29.

[NicholasBHubbard]

rebased onto main after merging #31

[NicholasBHubbard]

I added functionality for taking both local and remote zfs snapshots. I also added some pytest fixtures that will be useful for testing zfs code moving forward.

I have run into some issues however. Most importantly is I am realizing that the semantics of zfs do not fit into the current model/infrastructure of yaesm in the way that btrfs (and rsync) do. For example, the concept of a backup having a src_dir and dst_dir doesn't really make sense in the context of zfs. Take for example the following btrfs snapshot command:

$ btrfs subvolume snapshot -r /path/to/subvolume /path/to/new_snapshot

It is obvious in this command that /path/to/subvolume is the src_dir and /path/to/new_snapshot is the dst_dir. This is just how btrfs snapshots work. Contrast this with a zfs snapshot command:

$ zfs snapshot mypool/home/nick@new_snapshot

zfs snapshots operate on datasets, which are not denoted by filesystem paths. Really in the context of zfs, src_dir should be called dataset. Additionally, the destination of a zfs snapshot is determined automatically based on the dataset's mountpoint. For example, if a dataset is mounted at /mnt/foo, and you take a snapshot named new_snapshot, it will be accessible only at /mnt/foo/.zfs/snapshot/new_snapshot. This means that having a dst_dir option is irrelevant because we do not control where a zfs snapshot is stored, unlike Btrfs, where the destination can be explicitly specified.