I'm not sure that I fully understand the use case here. You can always mount /usr read only, or mount a ready only block device, even if the underlying filesystem is one that is potentially writeable in other circumstances. That is independent of the choice of filesystem.

While squashfs is supported, it is only supported for one specific use case for boot, and it not a generally supported filesystem. That said, there is no reason to think that it would not work in other scenarios, just that we would not support it as such.

If you are able to give us a bit more information about your use case, we may be able to suggest a better solution.

Hi Daan - 

Generally, we don't enable new features without a business case, because they have real and ongoing costs.  In the case of a new filesystem added to the OS, there's the kernel code, userspace utilities, test infrastructure, QE, documentation, support resources etc.  If you have a TAM, or a support contact, normally an RFE like this goes through those channels for evaluation, not as a bug.

That said, it's possible that we have an upcoming internal business case for erofs, so it might also get enabled for that reason.

Thanks,
-Eric

That makes sense, I mainly opened this to help me track when it gets enabled. I didn't really expect my use case to be sufficient to enable the feature. Good to hear that red hat might have an internal use case. Is it OK to leave this issue open to help track when it gets enabled?

To describe my use case more, in systemd's CI we build images with /usr on a read-only filesystem. This works on every distribution we support developing against except CentOS because it does not have the erofs module enabled. Having erofs in CentOS would allow us to get rid of the CentOS specific override and let us just use erofs everywhere. (This is just for extra context, I don't except this to be important enough to enable erofs in CentOS).

I'm still curious to know more. We can set any filesystem read only, so it isn't very clear why erofs is a dependency here.

Since this is systemd, that implies that it might be a special case for booting or something like that... is this likely to be a requirement for systemd going forward for some reason? Perhaps you might be able to describe what it is about this use case that means that other filesystems are not easily usable in this case.

As always, nothing is ever completely off the table, but at the same time, there are limits to what we can support and very often if we agree to support one particular feature, then that means we have to say no to something else. As such we try hard to ensure that we have the best combination of features enabled and supported, but there are some compromises that have to be made from time to time. The more info we have on the background of feature requests, the better able we are to make good decisions on which ones to support.

Reassigning this open bug to fs-maint.redhat.com as the old fs-maint mailing list has been deprecated.

Apologies, completely lost sight of this.

> Since this is systemd, that implies that it might be a special case for booting or something like that... is this likely to be a requirement for systemd going forward for some reason? Perhaps you might be able to describe what it is about this use case that means that other filesystems are not easily usable in this case.

erofs will never be a requirement for systemd. It's just that for our development images that we build locally and in CI, we have no need for a mutable /usr, so we prefer a read-only filesystem which makes the images smaller and faster to build. We prefer erofs instead of squashfs because it has a more active upstream community and supports more features.

To be clear, I don't think it makes sense to support erofs for just this use case. I consider this more as a tracking bug to find out when support becomes available because of potential other use cases for erofs.