-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transactional chroot maintenance on btrfs #2
Comments
|
However, /var/lib/nspawn-runner only needs to be writable by root, so we don't need to worry about creating temporary names securely |
|
Potentially, Naming the snapshots as This could also be used to get some kind of transactional behaviour on non-btrfs, by always recreating chroots from scratch during maintenance, and switching the symlinks in the end. One could argue, however, that if that's a needed feature, one could mount a btrfs partition on |
chroot-login
andchroot-maintenance
can be made transactional on btrfs by working on a snapshotted chroot, and replacing the production chroot in the end if everything went well.However, there is no straightforward atomic way to replace a subvolume in btrfs: https://btrfs.wiki.kernel.org/index.php/UseCases#Can_a_snapshot_be_replaced_atomically_with_another_snapshot.3F
However, we can have multiple snapshots per chroot, and use a symlink to atomically update which snapshot is the current one. To get rid of old snapshot,
btrfs subvolume delete
can be used as a more efficientrm -rf
.In case
nspawn-runner
does not like to see a symlink as an OS tree, inprepare
we can stillreadlink
the symlink and use the target as the OS tree for nspawn-runner.The text was updated successfully, but these errors were encountered: