Skip to content
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

Open
spanezz opened this issue Mar 15, 2021 · 4 comments
Open

Transactional chroot maintenance on btrfs #2

spanezz opened this issue Mar 15, 2021 · 4 comments

Comments

@spanezz
Copy link
Contributor

spanezz commented Mar 15, 2021

chroot-login and chroot-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 efficient rm -rf.

In case nspawn-runner does not like to see a symlink as an OS tree, in prepare we can still readlink the symlink and use the target as the OS tree for nspawn-runner.

@spanezz
Copy link
Contributor Author

spanezz commented Mar 15, 2021

btrfs subvolume snapshot supports a symlink to a subvolume directory as a source

@spanezz
Copy link
Contributor Author

spanezz commented Mar 15, 2021

btrfs subvolume snapshot does not support an existing empty directory as a destination. This means one cannot use mkdtemp to create a unique directory name for a snapshot.

However, /var/lib/nspawn-runner only needs to be writable by root, so we don't need to worry about creating temporary names securely

@spanezz
Copy link
Contributor Author

spanezz commented Mar 15, 2021

nspawn-runner is happy to use a symlink as an OS tree

@spanezz
Copy link
Contributor Author

spanezz commented Mar 15, 2021

Potentially, /var/lib/nspawn-runner/<image-name> could be a directory under which the snapshots are created, and which contains the symlink pointing to the current snapshot.

Naming the snapshots as $(date +%s)_$PID would be reasonably clash-free.

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 /var/lib/nspawn-runner instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant