Bug#947919: schroot: Support for ZFS snapshotting
On 03/01/2020 20:44, Steve Langasek wrote:
Package: schroot
Followup-For: Bug #947919
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch
Attached is an updated patch which implements source chroots as well.
Dear Steve,
I've had a look over the patch, and have a few comments on it.
Firstly, it looks really great. I've no major criticisms to make of it,
so many thanks for taking the time and effort to implement this, it's a
great addition.
If you hadn't already seen it, there's an existing implementation here:
https://gitlab.com/rleigh/schroot/commit/08751fdff2db4d11731983faf8e9868dffbd5dbf
on this branch:
https://gitlab.com/rleigh/schroot/tree/zfs-snapshot
I don't know if your work was using this as a basis for your work on top
of the 1.6 branch (the work here is against master, which is a bit
different). If you haven't already, it might be worth looking though.
I think, overall, your implementation is better in terms of the options
it provides and the environment it sets, but it might be useful to
compare just in case it has any interesting bits you want to pick up.
Note that I didn't complete this work; the C++ side was mostly done but
the scripting side for setting up the ZFS snapshots was not. At the
time, I wasn't entirely sure on how best to use ZFS to implement source
chroots reliably, which I think you've done better but I think not
completely (as detailed below).
When you clone a snapshot, you're getting an ephemeral dataset and
snapshot which the 05zfs script is correctly creating and destroying.
No problems here that I can see.
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.
One possible method would be to create an @latest snapshot which would
be used in preference to creating a new snapshot should it exist, so
that we could copy the content over while this snapshot exists. The
implementation would have to cope with races if it's deleted before
cloning, however, by falling back to creating a new snapshot. And only
the original creator should be deleting it, so it would also have to
cope with deleting it if the original process aborted without deleting it.
Another alternative which springs to mind is to make the source chroot a
directory chroot type, so it's working directly on the source dataset.
But snapshot with @latest-source and when others start a session, clone
that tag. When you end the session, update that tag. There's also the
option of rollback if you want to throw away the changes. This would
restrict you to one source chroot session at a time, but it's simpler
and has less to deal with in terms of races, and fits in a bit better
with how ZFS wants things done.
I'm sure some strategy could be worked out; these considerations were
the primary reason I never merged in that branch and made a new major
release of schroot. If you or anyone else has better expertise on how
to safely implement this, I'd be happy to work on merging your work into
the master branch and releasing this. Note however, that the master
schroot branch did made some incompatible configuration changes. The
biggest change was dropping support for the lvm-snapshot and
btrfs-snapshot chroot types, which in practice have proven quite
unreliable due to kernel and other implementation bugs, including races
in udev when using LVM and filesytem unbalancing and dataloss with
Btrfs. zfs-snapshot should be free of all these irritations.
Another comment regarding updating of the source chroot. With the
current methods, primarily 05file, the source is unconditionally updated
(repacked) when the session is ended. I've always been a little unhapy
with this, in case you mess things up and want to throw it away. This
would require an additional option adding to schroot to pass through
with --end-session. It would be a session option like --session-name.
Maybe --save-session to require the overwriting. Or a negative option
if you want the default to be to save. Or a Boolean option to make it
explicit and mandatory. With the @latest-source, above, this could
invoke "zfs rollback". Or with the other approach, you would throw away
the clone without updating the original dataset. This is really a
separate feature, but I wanted to mention it because it could have a
good deal of value for ZFS-based chroot management.
Lastly, I saw the buildds were failing due to an issue with the unit
test; looks like it needs updating to match the configuration serialisation?
Kind regards,
Roger
Reply to: