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

Use EROFS for the root filesystem #3456

Merged
merged 3 commits into from
Jul 24, 2024
Merged

Use EROFS for the root filesystem #3456

merged 3 commits into from
Jul 24, 2024

Conversation

sairon
Copy link
Member

@sairon sairon commented Jul 3, 2024

Switch to EROFS for the root filesystem, which promises better performance than SquashFS and with proper options set, it even achieves better compression.

Some hard numbers proving it's better choice are yet to be gathered but so far it looks fine.

@sairon sairon force-pushed the use-erofs-rootfs branch 2 times, most recently from 2958c58 to 889fb30 Compare July 10, 2024 12:42
Paths for images generated outside of genimage were not used in genimage
definitions. Use them as the single source of truth.

Images generated by genimage itself (e.g. kernel.img) don't need to use those
functions, so remove the unused ones.
* Enabled EROFS in common kernel fragment
* RootFS image switched to EROFS with options to get decent compression
* rootfstype removed from kernel command line
@sairon sairon requested a review from agners July 23, 2024 12:47
@sairon sairon added the os label Jul 23, 2024
@sairon sairon marked this pull request as ready for review July 23, 2024 12:47
Copy link
Member

@agners agners left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks! Looking forward to that one 🤩 .

@sairon sairon merged commit a80311a into dev Jul 24, 2024
2 checks passed
@sairon sairon deleted the use-erofs-rootfs branch July 24, 2024 14:34
@ThomDietrich
Copy link

Hey @sairon,
changes like this one make me wonder: These improvements do not make it into an existing setup. At which point would it make sense for users to consider a new install. Each individual improvement might not justify that but the combination of all could. I know this is not an easy question, there is probably not even a good answer for it.

First question that comes to my mind is whether a user can check with which OS version (and on which date) the initial setup was carried out. @agners is that visible anywhere in Supervisor, and should it?

If this line of question makes sense to you I'd be happy to raise it in a more appropriate place, e.g. under discussions. Apologies if a discussion thread on this already exists.

@sairon
Copy link
Member Author

sairon commented Aug 14, 2024

Hi @ThomDietrich 👋

These improvements do not make it into an existing setup.

You're not quite right. This changes the whole rootfs partition which is read-only and gets changed also for existing installations (you can check mount output - directly on the host though, not in a terminal/SSH container). The situation would have been different if we changed partition type or flags of any of the overlay or data partitions, but in that case the OTA hook will likely be adjusted to handle this situation.

On the other hand, sometimes there are changes that do not make its way to existing installations. Generally it'd be changes of the partitioning, or changes in config.txt or cmdline.txt in the boot partition. In that case we consider if a migration mechanism is needed too, or we just ignore the change, because it's likely important for new installs only (for example when adding USB quirks to disable misbehaving UAS driver on RPi).

@ThomDietrich
Copy link

Hey @sairon, thanks for the long response!
With your explanation that makes total sense. Much appreciated :)

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

Successfully merging this pull request may close these issues.

3 participants