-
Notifications
You must be signed in to change notification settings - Fork 50
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
disk_layout: use btrfs for the /usr partition #1170
Conversation
The compression feature of btrfs allows us to store more in the size-limited /usr and OEM partitions. The size should of course still be monitored to not bloat the image but more headroom helps to try things out quickly without hitting the hard limit which fails the build. Use btrfs with zstd compression for the /usr partition. While for ext2 a hack exists to force read-only mounts by manipulating some bytes of the filesystem, on btrfs we can use the subvolume read-only flag instead which also works for the default top level subvolume. However, it also makes also sense to mount the filesystem with the "norecovery" mount option to prevent any write attempts even when the "ro" option is set (not needed when using dm-verity in read-only mode but when directly mounting without dm-verity). A new subvolumes is not created because subvolumes don't offer anything special as long as we use the A/B partition update mechanism (but they could be an alternative for that). Note that switching to the btrfs on the /usr partition is only possible when the Flatcar Stable release has all patches in update-engine and seismograph's rootdev.
e139144
to
04dbade
Compare
Question: Is the updated /usr partition (USR-A or USR-B) going to be reformatted during update from ext2 to compressed btrfs? |
Build action triggered: https://github.com/flatcar/scripts/actions/runs/6572198147 |
The update writes the whole partition image out. This means the old ext2 fs is gone and any new filesystem like btrfs is there. |
When should we merge this? On one hand we could wait until we really hit the size limit, and on the other it's actually good to merge while having wiggle room so that we can revert it later if we hit an unforeseen problem and aren't forced to find a solution because we with the revert we would hit the limit already. |
Yeah, we have entire alpha and beta periods to catch issues. |
The compression feature of btrfs allows us to store more in the size-limited /usr and OEM partitions. The size should of course still be monitored to not bloat the image but more headroom helps to try things out quickly without hitting the hard limit which fails the build.
Use btrfs with zstd compression for the /usr partition. While for ext2 a hack exists to force read-only mounts by manipulating some bytes of the filesystem, on btrfs we can use the subvolume read-only flag instead which also works for the default top level subvolume. However, it also makes also sense to mount the filesystem with the "norecovery" mount option to prevent any write attempts even when the "ro" option is set (not needed when using dm-verity in read-only mode but when directly mounting without dm-verity). A new subvolumes is not created because subvolumes don't offer anything special as long as we use the A/B partition update mechanism (but they could be an alternative for that). Note that switching to the btrfs on the /usr partition is only possible when the Flatcar Stable release has all patches in update-engine and seismograph's rootdev.
(Taken from the comment in #131)
How to use
We need to document the minimal required Flatcar version to update. Ideally Nebraska would help with that: flatcar/Flatcar#1185
Minimal Stable version is https://www.flatcar.org/releases#release-2983.2.0
This means that the current 3033 LTS is good but our very first 2605 LTS is not supported for updating.
New filesystem usage on
/usr
:Testing done
Here, required a fix in kola: flatcar/mantle#453
changelog/
directory (user-facing change, bug fix, security fix, update)/boot
and/usr
size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.