Bug#947919: schroot: Support for ZFS snapshotting
On 04/01/2020 12:54, Roger Leigh wrote:
When you clone a source snapshot, we want to make that snapshot the
default state for the original dataset when you end the session. The
"file" chroot type is the most comparable here; the LVM and Btrfs
snapshots operate directly on the original copy. Right now the ZFS
source chroot clone looks as ephemeral as a regular cloned session, so
I'm not sure the current behaviour is corect. We want the saving of
the updated source chroot to be done such that it appears atomic for
any concurrent usage to clone the old state or the new state, and
never an intermediate state as the original is updated. It's this
part that I wasn't sure about. I don't see an equivalent to "zfs
promote" which would allow copying back a clone (or snapshot of a
clone) to the source dataset, and I don't see any
source-chroot-specific logic in 05zfs which would preserve any source
chroot changes.
I should also have written that I did also consider if we could use "zfs
promote" as intended. It should be fine for its intended purpose, but
it would change the dataset name which would then require an update of
schroot.conf. I ruled this out because it doesn't fit into the existing
design. However, were schroot to eventually become a service, we could
create and manage chroots similar to docker and not have the chroot
configuration in /etc at all; it would be all stored as data under /var.
Reply to: