On Thu, Jan 16, 2025 at 4:13 PM Phillip Lougher <phillip.lougher@xxxxxxxxx> wrote: > > 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). > As I am one of the snap stack maintainers in Fedora and EPEL, I do not care about this fight. I do know that the OCI world is adopting EROFS, and Flatpak is getting sucked into that. I couldn't care less about the Flatpak vs Snap thing, as I prefer to use neither. I use some Flatpaks and snaps as I am required to, but otherwise prefer regular packaging systems like RPM. 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. I had also been previously concerned about the long dry spell around squashfs-tools maintenance, but that situation has improved in recent years. No one is proposing to drop SquashFS in Fedora, certainly not me. > > 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/nostalgia/ive-bridge-sell-you-conman-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/latest/comparsion/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. > I am aware of the bias. My tests were done with much more equivalent settings. Kiwi built images have used 1MB blocks for quite some time for squashfs, and I force the same block size for EROFS in our kiwi definitions. Initially, EROFS was >50% larger than SquashFS and getting it to comparable size would blow out the image build time by 5x. The EROFS developers noticed my comparisons and worked to improve both compression and time to creation to make it possible to match SquashFS. As one of the upstream developers for the kiwi image build tool, I have no intention of removing SquashFS support. It's perfectly fine and usable. My only issue with it is that using unsquashfs to install live environments causes the environment to freeze, which is not great. This doesn't affect Anaconda, but it does affect Calamares (which Fedora itself does not use). And EROFS does have a couple of downsides right now for the CoreOS folks (notably the lack of single file extract), but they want to switch to it anyway for technology consolidation reasons (as I mentioned earlier). -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
