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/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. Phillip --- Dr. Phillip Lougher (Squashfs author and maintainer) -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
