To be clear, I'd prefer at least the following options so ACLs and SELinux can be used.

CONFIG_EROFS_FS=m
CONFIG_EROFS_FS_XATTR=y
CONFIG_EROFS_FS_POSIX_ACL=y
CONFIG_EROFS_FS_SECURITY=y

Since 5.4 was allowed to promote to Fedora 31 now, I'd also like to request the feature be enabled in the f31 branch.

Same for f30 now.

Hi,

Just noticed this, and I'd also like if some chance on Fedora as well...

EROFS has already been enabled as a kernel module in openSUSE and Debian,
and here is the Debian configration:

https://salsa.debian.org/kernel-team/linux/commit/33639568475c399acc9cd9d45e9b06a3a2df6e75

##
## file: fs/erofs/Kconfig
##
CONFIG_EROFS_FS=m
# CONFIG_EROFS_FS_DEBUG is not set
CONFIG_EROFS_FS_XATTR=y
CONFIG_EROFS_FS_POSIX_ACL=y
CONFIG_EROFS_FS_SECURITY=y
CONFIG_EROFS_FS_ZIP=y
CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1

It'd be appreciated folks could take some time evaluating this filesystem for
more scenarios, raise up useful feature request proposals and contribute it
if have extra time...

I will devote myself to this all the time.

Thanks,
Gao Xiang

Hi Gao Xiang,

Would you like to maintain the Fedora userspace pkg?  I think this needs two bugs, one for userspace pkg, another for the kernel options.

Thanks
Dave

Oh, fedora.dm0 wrote a spec file, probably he/she want to maintain it

Since this is for the kernel, so need a separate bug for the utils pkg review, please refer to below bz:
https://bugzilla.redhat.com/show_bug.cgi?id=1782532

(In reply to Gao Xiang from comment #4)
> Hi,
> 
> Just noticed this, and I'd also like if some chance on Fedora as well...
> 
> EROFS has already been enabled as a kernel module in openSUSE and Debian,
> and here is the Debian configration:
> 
> https://salsa.debian.org/kernel-team/linux/commit/
> 33639568475c399acc9cd9d45e9b06a3a2df6e75
> 
> ##
> ## file: fs/erofs/Kconfig
> ##
> CONFIG_EROFS_FS=m
> # CONFIG_EROFS_FS_DEBUG is not set
> CONFIG_EROFS_FS_XATTR=y
> CONFIG_EROFS_FS_POSIX_ACL=y
> CONFIG_EROFS_FS_SECURITY=y
> CONFIG_EROFS_FS_ZIP=y
> CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1
> 
> It'd be appreciated folks could take some time evaluating this filesystem for
> more scenarios, raise up useful feature request proposals and contribute it
> if have extra time...
> 

Hi, we maintains kexec/kdump component in Fedora, and currently we use squashfs for kdump initrd to save memory, probably we can try erofs see if it runs better.

(In reply to Dave Young from comment #6)
> Oh, fedora.dm0 wrote a spec file, probably he/she want to maintain it

No thanks, I build the tools locally.  This is a request for the kernel so I can use the produced images on Fedora.  Someone can take the attached spec file if they want to maintain it for Fedora.

(In reply to Dave Young from comment #5)
> Hi Gao Xiang,
> 
> Would you like to maintain the Fedora userspace pkg?  I think this needs two
> bugs, one for userspace pkg, another for the kernel options.
> 
> Thanks
> Dave

Hi Dave,

Thanks for your reply.

I'm not familiar with the whole .rpm stuffs but it seems openSUSE has accepted erofs-utils as well...

I'm currently using Debian and maintaining its .deb package.
If David has some interest in that, I'm happy that he could take some time on this package.

Hi David,
Is there some chance on this userspace package?
I will fix all the reported issues in upstreaming so I think it would be easy to maintaining this package for Fedora...

> Hi, we maintains kexec/kdump component in Fedora, and currently we use squashfs for kdump initrd to save memory, probably we can try erofs see if it runs better.

EROFS still isn't good at high compression ratio scenarios yet, I'm struggling in developping fixed-sized output XZ (LZMA2) algorithm.
So for now I think the dynamic performance could be better, but I'm not sure if the current compression ratio meets your original requirement.
But anyway, high CR algorithm supports are on the way...

Thanks,
Gao Xiang

> EROFS still isn't good at high compression ratio scenarios yet, I'm
> struggling in developping fixed-sized output XZ (LZMA2) algorithm.
> So for now I think the dynamic performance could be better, but I'm not sure
> if the current compression ratio meets your original requirement.
> But anyway, high CR algorithm supports are on the way...

Thanks for the explanation, good to know about the plan :)

(In reply to Dave Young from comment #11)
> > EROFS still isn't good at high compression ratio scenarios yet, I'm
> > struggling in developping fixed-sized output XZ (LZMA2) algorithm.
> > So for now I think the dynamic performance could be better, but I'm not sure
> > if the current compression ratio meets your original requirement.
> > But anyway, high CR algorithm supports are on the way...
> 
> Thanks for the explanation, good to know about the plan :)

I'm doing that in my spare time, mainly due to enriching community ecosystem
rather than our products (so rare company support).

LZMA fixed-sized output compression can be implemented in principle, I'm coding
now (range coder and LZ matchfinder is almost ready), and need debugging.
Hopefully can be done first half past of this year.

Thanks,
Gao Xiang

(In reply to Gao Xiang from comment #12)
> (In reply to Dave Young from comment #11)
> > > EROFS still isn't good at high compression ratio scenarios yet, I'm
> > > struggling in developping fixed-sized output XZ (LZMA2) algorithm.
> > > So for now I think the dynamic performance could be better, but I'm not sure
> > > if the current compression ratio meets your original requirement.
> > > But anyway, high CR algorithm supports are on the way...
> > 
> > Thanks for the explanation, good to know about the plan :)
> 
> I'm doing that in my spare time, mainly due to enriching community ecosystem
> rather than our products (so rare company support).
> 
> LZMA fixed-sized output compression can be implemented in principle, I'm
> coding
> now (range coder and LZ matchfinder is almost ready), and need debugging.
> Hopefully can be done first half past of this year.
> 
> Thanks,
> Gao Xiang

Hi, thanks for the work, I'll definitely try it out when that's ready.

Will it have a higher compression ratio and less memory usage than squashfs? kdump maybe benefit from it.

(In reply to Kairui Song from comment #13)
> (In reply to Gao Xiang from comment #12)
> > (In reply to Dave Young from comment #11)
> > > > EROFS still isn't good at high compression ratio scenarios yet, I'm
> > > > struggling in developping fixed-sized output XZ (LZMA2) algorithm.
> > > > So for now I think the dynamic performance could be better, but I'm not sure
> > > > if the current compression ratio meets your original requirement.
> > > > But anyway, high CR algorithm supports are on the way...
> > > 
> > > Thanks for the explanation, good to know about the plan :)
> > 
> > I'm doing that in my spare time, mainly due to enriching community ecosystem
> > rather than our products (so rare company support).
> > 
> > LZMA fixed-sized output compression can be implemented in principle, I'm
> > coding
> > now (range coder and LZ matchfinder is almost ready), and need debugging.
> > Hopefully can be done first half past of this year.
> > 
> > Thanks,
> > Gao Xiang
> 
> Hi, thanks for the work, I'll definitely try it out when that's ready.
> 
> Will it have a higher compression ratio and less memory usage than squashfs?
> kdump maybe benefit from it.

I will send out XZ RFC solation after it is worth to be tried out.

My current estimate is
On lower compress cluster size it would have higher compression ratio than squashfs,
On larger compress cluster size compression ratio of EROFS is close to squashfs.

Due to in-place decompression (no extra memory allocation and memcpy), its dynamic
memory overhead is smaller than squashfs.

Thanks,
Gao Xiang

I will enable this in rawhide for the next build, it will trickle down to F31 and F30 as the 5.5 rebases happen, which should give some time to get the userspace utilities built and sorted.

I submitted the spec in #1789492.

This can probably be closed since the kernel functionality is enabled in rawhide, unless it's supposed to be blocked by the userspace package.

The userspace tools have been added, and the kernel support will promote from rawhide, so I'll close this.