Fedora 42 Is Looking At Switching To EROFS For Its Live Media

[phoronix]

Phoronix: Fedora 42 Is Looking At Switching To EROFS For Its Live Media

A change proposal filed today for the in-development Fedora 42 is looking at making use of the EROFS file-system for all of the live media images...

https://www.phoronix.com/news/Fedora-42-Considers-EROFS

[phillip_lougher]

Squashfs is actively maintained, and so I dispute the claims made here and in the change proposal.

There is a new Squashfs-tools release with new features imminent, and the kernel code has seen improvements last year too.

EROFS is playing catch-up in many areas and still adding new features that Squashfs has had for many years (such as a parallel Mksquashfs and Unsquashfs).

But in many cases the community gets what it pays for. There are a large number of EROFS developers and companies like Alibaba and ByteDance are paying developers to work on it.

In contrast I'm the only developer on Squashfs, and I'm still having to work on it in my spare time after over 23 years, because no company has offered to pay me to work on it. So there it is.

[phillip_lougher]

I could also be sarcastic here and point out that Fedora LiveCDs only use Squashfs as container for another filesystem (ext4), which has never been a good way of doing it, using none of its advanced features. So the reason to move to EROFS seems less like a technical reason, and more because it is new and shiny.

[Marth Koopa]

I can't not read EROFS as Erotic File System

[Kjell]

Interesting

EROFS is also the new default System Partition since Android 13, or Pixel 7. However, user data still uses F2FS.

Google claims this change from Ext4 causes the system partition to perform +20% faster while requiring 2gb less space

Benchmark

https://www.usenix.org/system/files/atc19-gao.pdf

Announcement

https://consumer.huawei.com/jo/emui-9-1/

[Weasel]

Squashfs is actively maintained, and so I dispute the claims made here and in the change proposal.

There is a new Squashfs-tools release with new features imminent, and the kernel code has seen improvements last year too.

EROFS is playing catch-up in many areas and still adding new features that Squashfs has had for many years (such as a parallel Mksquashfs and Unsquashfs).

But in many cases the community gets what it pays for. There are a large number of EROFS developers and companies like Alibaba and ByteDance are paying developers to work on it.

In contrast I'm the only developer on Squashfs, and I'm still having to work on it in my spare time after over 23 years, because no company has offered to pay me to work on it. So there it is.

Thank you for all your work on Squashfs and maintaining it. It is an understatement to say I use it a lot. I even use as my immutable root filesystem (overlayed for temporary changes, except when I'm updating on purpose), containers, etc.

[finalzone]

I could also be sarcastic here and point out that Fedora LiveCDs only use Squashfs as container for another filesystem (ext4), which has never been a good way of doing it, using none of its advanced features. So the reason to move to EROFS seems less like a technical reason, and more because it is new and shiny.

Feel free to discuss on https://lists.fedoraproject.org/arch...IX6BWAGEL6GKJ/

[Garp]

So the reason to move to EROFS seems less like a technical reason, and more because it is new and shiny.

I agree, the lack of any actual justification for the change in the proposal would echo that. What they put was utterly meaningless:

EROFS is considerably more actively developed than SquashFS, and offers more modern file system features that can be utilized in the future.

That is just not any kind of technical justification at all. If I saw that in a proposal at work I would reject it immediately. If you can't tell me what the actual tangible benefits are, what it enables that the previous method didn't enable, I'd consider it a complete waste of engineering time and not something I'd be willing to help champion with leadership. It's the kind of justification I'd expect from junior engineers that haven't got rid of the "oooh shiny" habit yet.

I'm absolutely baffled that the proposers thought this was sufficient justification.

[King InuYasha]

I could also be sarcastic here and point out that Fedora LiveCDs only use Squashfs as container for another filesystem (ext4), which has never been a good way of doing it, using none of its advanced features. So the reason to move to EROFS seems less like a technical reason, and more because it is new and shiny.

The ext4 inner volume is not present in the kiwi-built images, it's a plain squashfs setup.

[phillip_lougher]

Feel free to discuss on https://lists.fedoraproject.org/arch...IX6BWAGEL6GKJ/

Thanks for pointing that out. FYI this is what I said on there.

Neal Gompa wrote:

> > It's mostly that it behaves more like a real filesystem. It uses
> extents, supports inline compression, DAX, and other features that you
> expect from advanced filesystems.

That's just word salad. Squashfs is a real filesystem, with real filesystems techniques: inodes, extents, inline compression (I think you mean inline decompression here). In fact it has the features that EROFS has, and it has had them for years.

There's one thing the EROFS developers never talk about, and that's metadata compression. EROFS doesn't do it, but Squashfs does, and it has done since 2002.

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?

You say you have worked with the EROFS developers to improve compression. I see no dialogue or discussion with me, or on Squashfs websites/mailinglists where you reached out to voice your issues/concerns with Squashfs and have them addressed. This strikes me as putting the cart before the horse, and suggests the motivation is not driven by technical problems with Squashfs, but because EROFS is seen as newer or there are politics involved, with Squashfs being sucked into the Flatpak/Snap standoff. I have absolutely nothing to do with Canonical or Snaps. If you don't want people to run Snaps on Fedora, don't do it via the backdoor of deprecating and then disabling Squashfs (I notice Squashfs is deprecated on RHEL 10 and is to be removed for no discernible technical reason).

> There's a lot more detail about it on the EROFS website:
> https://erofs.docs.kernel.org/en/latest/

If you believe everything that the EROFS developers claim then I've got a bridge to sell you (https://www.mylondon.news/news/nosta...onman-22497002).

The tests are all done in way to flater EROFS and put Squashfs in the worst light. For example see https://erofs.docs.kernel.org/en/lat...on/dedupe.html. They deliberately disable Squashfs metadata compression because EROFS doesn't support it, and use 128K blocks despite Squashfs supporting 1Mbyte blocks (look for the line [1] SquashFS uses –b 131072 by default, -noI will disable its metadata compression.). By doing this they deliberately reduce the compression and speed of Squashfs in their tests. This IMHO is biased and unethical. But that is how it is.

So far this proposal looks like something from the EROFS marketing department and is remarkably light in motivations and technical detail.

Phillip

---
Dr. Phillip Lougher (Squashfs author and maintainer)