Red Hat Developers Announce Work On New "Composefs" File-System

[timofonic]

The obvious use of composefs is to create a tragic opera about Hans Reiser.

Jack(D) the Ripper, System of a Down, Hans Reiser. .

[gregzeng]

Red Hat (owned by IBM) is trying to launch another file system. Eventually this will be compared and contrasted to the many existing file systems.

Several questions. How open source will it be allowed, or will it need commercial licensing to be used fully. What are its overall strengths and weaknesses. Instead of modifying or evolving existing systems, these profit-focused commercial businesses decided to often this new innovation.

Eventually, the many types of end-users must decide again. Will those innovation survive, or instead of statistical normality, just sorry on the shelf, almost forgotten.

[skierpage]

Eventually, the many types of end-users must decide again. Will those innovation [another file system] survive, or instead of statistical normality, just sorry on the shelf, almost forgotten.

Go back and re-read "some of the main highlights" from Alexander Larsson:

we have a fully verified filesystem tree mounted, with opportunistic fine-grained sharing of identical files... Secondly we are interested in using the verification aspects of composefs in the ostree project.

If this works out, anyone who interacts with a container or uses flatpak apps on Red Hat/Fedora-derived OSes will be enjoying these benefits of composefs, without making any decision of their own.

RedHat/Fedora is improving Linux features like secure operation, containers, and sandboxed apps by improving the interrelated projects they build on (secure boot, verification and attestation, systemd, bwrap, OSTree, podman, file-system deduplication, XDG portals, ...). It's complicated under the covers but for users the features just work and get better. To me it's inspiring, and seems to be delivering results, as opposed to say Canonical developing a more monolithic dump like snaps.

Edit: Note that composefs isn't a new on-disk file system format like ext4 or xfs. It's a layer above such a file system pointing to file contents on-disk. From the LKML e-mails:

However, instead of storing the file content each regular file inode stores a relative path name, and the filesystem gets the file content from the filesystem by looking up that filename in a set of base directories. ... the files are content addressed (i.e. named by content digest)