Announcement

Collapse
No announcement yet.

EROFS-Utils 1.4 Adds Experimental FSCK, MicroLZMA Compression

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • EROFS-Utils 1.4 Adds Experimental FSCK, MicroLZMA Compression

    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?pa...ROFS-Utils-1.4

  • #2
    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?
    Last edited by tildearrow; 22 November 2021, 01:05 AM.

    Comment


    • #3
      Originally posted by tildearrow View Post
      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.

      Comment


      • #4
        Originally posted by tildearrow View Post
        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"

        Comment


        • #5
          Originally posted by tildearrow View Post
          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.

          Originally posted by tildearrow View Post
          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?

          Comment


          • #6
            Originally posted by discordian View Post
            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.

            Comment


            • #7
              Originally posted by sinepgib View Post

              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.

              Comment


              • #8
                Originally posted by discordian View Post
                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.

                Originally posted by discordian View Post
                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?

                Comment


                • #9
                  Originally posted by sinepgib View Post
                  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.

                  Originally posted by sinepgib View Post
                  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.

                  Comment

                  Working...
                  X