relnotes.info

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== EROFS for Live Media ======

A [[https://fedoraproject.org/wiki/Changes/EROFSforLiveMedia|proposed]] //self-contained// change for Fedora 42 is substituting [[https://erofs.docs.kernel.org/en/latest/|EROFS]] for SquashFS in the Live media artifacts.

Thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DUXPAZLU7K2DGREXCX2IX6BWAGEL6GKJ/

The author/maintainer of SquashFS had some thoughts, which seemed appropriate given how sparse the [[https://fedoraproject.org/wiki/Changes/EROFSforLiveMedia|Change's wiki page]] is by way of context, as well as a good reminder to include them when proposing changes anywhere:

> In a supposedly technical proposal, I would have expected to see at the least:
>
> 1. Motivations and reasons for why it is necessary, including:
>  1.1 The current pain points with Squashfs.  Is there a problem with compression size? Speed? Reliability?
>  1.2 The techniques that EROFS has that solves these problems.
>  1.3 Real world tests and benchmarking results that backup/illustrate the problems and the solution.
>
> 2. A risk analysis of the possible consequences:
>  2.1 In real-world situations is EROFS less or more stable than Squashfs with corrupted images.
>  2.2 Have you tested?  What were the results?  Undetected file corruption?, kernel OOPses?, lockup?

===== But Why? =====

Historical context was interesting on its own with regards to the future of EL:

> The initial driver for exploring the switch was because RHEL 10 is dropping SquashFS support. > My guess about that is that since the OCI world and Red Hat's bootc are using EROFS (through > composefs), they want to consolidate things around it.

The maintainer/developer of EROFS also chimed in:

> Please note, EROFS was once proposed to resolve SquashFS unacceptable random runtime performance issues on the high-performance Android scenerios, and almost all smartphone vendors on the market use EROFS now.

> Anyway, EROFS was once specifically designed for Android devices initially

Interesting! Coupled with a note further down adding more context to this decision:

> This all started because OCI's usage of tarballs to make "images" turned out to be a poor choice .... I don't even know why SquashFS wasn't considered for OCI.

From what I can gather, it seems that EROFS was not designed for this use case, the EROFS maintainer (singular?) "doesn't care" about the features/performance for this use case, //and// SquashFS was never considered to begin with.

As I read through this thread I can only echo this statement:

> [...] it seems EROFS  offers no direct benefit in the short term (reading some of this thread  it actually seems to come with some drawbacks, which the maintainer(s) are trying to address in their spare time?).

===== Operating Systems within Operating Systems within ... =====

The later discussion seems to only focus on the container ecosystem, as a co-owner of the proposal stated:

>  I'm interested mainly in upstream and downstream alignment between the Fedora CoreOS and RHEL CoreOS ISO images. It appears erofs is where we are headed in the future and I'd like to get out ahead of it and do things upstream first.

With an apparently "significant degradation of compression ratios, compression times, and
decompression times.", it seems there is a lack of care or thought to those using Live ISO's to install Fedora on physical machines, which is unfortunate.

===== Extra Notes / Opinions =====

Together with [[https://www.suse.com/c/suse-salp-raises-the-bar-on-confidential-computing/|(open)SUSE]] moving to an immutable distro, I am a bit concerned with this "consolidation" and the (perceived) treatment of all physical machines as if they are phones.

My concerns are mostly with reduced control and general repair-ability, though maybe I just haven't had enough experience with containers/bootc and the ~cloud~ computing world. 

There are a lot of issues with both the actual operating systems on bare metal hardware as well as the human education/training side of things, but I don't think papering over everything with abstractions is a particularly nice way to go about things. Not everything is or should be implemented as a megacorp cloud architecture, and IBM has the resources to build Live ISO's with SquashFS and the container ISO's with something else.