On Wed, Jan 29, 2025 at 03:11:43PM -0500, Dusty Mabe wrote: > On 1/22/25 7:17 AM, mkolman@xxxxxxxxxx wrote: > > On Wed, 2025-01-22 at 11:19 +0100, Simon de Vlieger wrote: > >> Hi Neal (and Dusty), > >> > >> On 1/15/25 11:53 PM, Aoife Moloney via devel-announce wrote: > >>> EROFS is considerably more actively developed than SquashFS, and > >>> offers more modern file system features that can be utilized in the > >>> future. > >> > >> Reading some through some of the thread it seems the main motivation > >> is > >> consolidation of tooling across the OCI, RHEL, and (through OCI) > >> Flatpak > >> landscape. Could you maybe add that little blurb to the change > >> proposal > >> wiki? > >> > >> > >> Aside; I'm perhaps a bit conservative in this regard but 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?). > >> > >> Could you expand on the benefits and possible future benefits that > >> make > >> the change necessary? > > Yeah - I do wonder the benefits are really larger than the risks, given > > the performance/efficiency issues & unclear timeline for those issues > > to be resolved. > > > > Do we really need to rush this now instead of waiting for the issues to > > be resolved first & then switching to an objectively better FS ? > > From my side (I'm a co-owner of the proposal) 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. > > We do test the Fedora CoreOS install media on every pipeline run (i.e. if > we don't pass tests we don't ship anything), so presumably if erofs proves > unreliable we just won't ship it. > > Ultimately for our users this should be a transparent change without requiring > any action on their part. In the discussions around the proposal, some measurements that showed significant degradation of compression ratios, compression times, and decompression times. Do we have some measurements of all those things after the latest improvements? So far the only concrete benefit is the alignment of RHEL and Fedora. But this isn't even mentioned in the proposal. I think it'd have been better to have that there, with an explanation why the alignment is useful. Otherwise, we're buying a pig in a poke. As Simon de Vlieger wrote above, there certainly are risks and costs with a switch like this, and the benefits are not really being shown right now. Zbyszek -- _______________________________________________ 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
