Hi Roger, On Sat, Jan 04, 2020 at 12:54:56PM +0000, Roger Leigh wrote: > If you hadn't already seen it, there's an existing implementation here: > https://gitlab.com/rleigh/schroot/commit/08751fdff2db4d11731983faf8e9868dffbd5dbf Ah no, I had not seen this! There don't appear to be any references to this gitlab repository anywhere in the existing source package. > 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). I'm largely happy with what I have here now, but if you think there are specific learnings I should take from your branch, I'm happy to look. > 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. Ok, you're right that I haven't done anything wrt 'zfs promote'. Prior to switching to zfs, all of my schroot work used the lvm-snapshot type, which has the same limitation you describe here: session clones taken while the source chroot is in the process of being updated end up cloning some intermediate state. I have never had a problem with this limitation in practice, since my usage of schroot is entirely human-driven, so it's very easy for me to avoid launching new schroots while in the middle of a "maintenance window". Being able to update the source atomically certainly seems like a nice enhancement, but given that the implementation is currently at parity with the lvm-snapshot type, I am not likely to invest effort in this myself at this time. > 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. > 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? This it turns out was caused by a bug in debian/rules, which failed to run the test suite at all when called via dpkg-buildpackage -b (instead of -B). I recall being surprised that my changes didn't introduce any new test failures, but failed to notice the tests were not being run. I'll follow through on this, thanks for bringing it to my attention. On Sat, Jan 04, 2020 at 02:35:47PM +0000, Roger Leigh wrote: > 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. > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature