EROFS-Utils 1.4 Adds Experimental FSCK, MicroLZMA Compression

[phoronix]

Phoronix: EROFS-Utils 1.4 Adds Experimental FSCK, MicroLZMA Compression

EROFS-Utils as the collection of open-source user-space utilities for the read-only EROFS file-system is out with a big update...

https://www.phoronix.com/scan.php?page=news_item&px=EROFS-Utils-1.4

[tildearrow]

EulerOS Read-Only File System

Error Read-Only File System

EROtic File System


Seriously, I wonder how does this compare against SquashFS. Is this more like a "file-system" and less like a "tar" or "cpio"? Or was it only designed so Huawei could have more control over the file-system?

[NateHubbard]

EulerOS Read-Only File System

Error Read-Only File System

EROtic File System


Seriously, I wonder how does this compare against SquashFS. Is this more like a "file-system" and less like a "tar" or "cpio"? Or was it only designed so Huawei could have more control over the file-system?

"EROFS file-system stands for Enhanced Read-Only File System. Different from other read-only file systems, it aims to be designed for flexibility, scalability, but be kept simple and high performance."

But, likely someone just wanted to do things their way.

[CochainComplex]

Or was it only designed so Huawei could have more control over the file-system?

In this case I would like to have seen something like "WPMFFS - Winnie Pooh's most favorite FS"

[discordian]

Seriously, I wonder how does this compare against SquashFS. Is this more like a "file-system" and less like a "tar" or "cpio"?

Basically, yes. Its constructed to map nicely to filesystem operations and keeping information locally contained. For reading you will have alot excess reads (whole additional blocks) and need more memory/state with squashfs.
The only downside until 5.16 was that squashfs could create smaller images by using bigger blocks and better compression.

TBH, I hope in future, all tools will support it, making it a (seekable and mountable) replacement for tar.

Or was it only designed so Huawei could have more control over the file-system?

What are your options if you change the on-disk layout of squashfs then its not squashfs anymore?
Otherwise, what would be the point?

[sinepgib]

TBH, I hope in future, all tools will support it, making it a (seekable and mountable) replacement for tar.

Hmmm, I'd rather have a tar extension that appends a special empty file with an index to the archive. That should suffice for getting both of those operations while keeping it compatible with regular tar I think.

[discordian]

Hmmm, I'd rather have a tar extension that appends a special empty file with an index to the archive. That should suffice for getting both of those operations while keeping it compatible with regular tar I think.

Such a thing is fundamentally opposing how tar works, you can cat archives together after all.

What I am after is a complete chain of having a set of archives, combining them (filter, replace, add-as-subdirectory) and passing them to say mkfs.ext4.
Reason is that handling stuff like sticky bits and xattrs is rather fragile, and that can hurt you if you build root filesystems from multiple components. Some tools will just bug out if you use fakeroot and xattrs.
with erofs + overlayfs you could aswell just mount the components for testing.

[sinepgib]

Such a thing is fundamentally opposing how tar works, you can cat archives together after all.

Well, you don't need to. There are several uses for tar, not all of them being actual tape archiving. What I propose shouldn't break that ability, it would simply not provide that extra functionality on concatenated archives. It should still be compatible with previous versions AFAICT.

What I am after is a complete chain of having a set of archives, combining them (filter, replace, add-as-subdirectory) and passing them to say mkfs.ext4.
Reason is that handling stuff like sticky bits and xattrs is rather fragile, and that can hurt you if you build root filesystems from multiple components. Some tools will just bug out if you use fakeroot and xattrs.
with erofs + overlayfs you could aswell just mount the components for testing.

Wouldn't a set of OverlayFS built atop this proposed tar extension work similarly to this?

[discordian]

Well, you don't need to. There are several uses for tar, not all of them being actual tape archiving. What I propose shouldn't break that ability, it would simply not provide that extra functionality on concatenated archives. It should still be compatible with previous versions AFAICT.

Then you hardly can depend on this working, its bad enough with tar having 2-3 extension with ustar, pax and implementations having different kind of support.

Wouldn't a set of OverlayFS built atop this proposed tar extension work similarly to this?

The thing is, that tar is more or less an archival utility, you cant even store content compressed (just can compress the whole thing) thus you have to decompress + re-compress for every copied file instead of copying the compressed content.
cpio/tar are the stupidest formats when it comes for handling the content (ie usecases where you need more random access), using zip/rar/7z would be a better start. Making a mountable FS like erofs your archive even better.

For production system -> dd the archive(s) on flash. Works
For tests -> loop mount. Works

Unpacking/Packing just has so many cases where devs/properties/special permissions are lost because of access rights or mount options.