Ctrl+K

Native sub-filesystem merging

Native sub-filesystem merging#

In addition to the OSTree/Composefs file-based model, EROFS itself supports three native forms to merge common external binary sources (like sub-filesystem layers) into one filesystem and mount the merged filesystem in one go.

Single device#

Unlike other kernel filesystems which have inflexible layouts, EROFS has only one fixed-offset ondisk part: the superblock. It’s quite easy to compose external payloads such as binary formats like tarballs or other filesystems (e.g., EROFS, EXT4, XFS, etc.) just with linear physical mappings to form the entire filesystem view.

It’s particularly useful for virtualization cases since only one EROFS mount will be passed in via virtio-blk or virtio-pmem instead of individual parts.

Single block device with sub-filesystems

Especially for each virtio-pmem instance, the host page cache can be easily shared at a finer sub-image granularity due to linear physical mappings compared to other approaches, which are typically based on traditional disk snapshots.

Tip

This way has already been usable since the initial EROFS version. However, if your use cases also cover multiple devices, an ondisk device table will be needed then; See below.

Multiple devices / blobs#

Since Linux 5.16, EROFS has supported multiple devices explicitly as its external data sources. EROFS device table can indicate external data on extra devices as below:

Multiple block devices with sub-filesystems

Besides, it is quite useful for scenarios where we have no way to compose a single specific block device from individual sources as described in the previous section.

In addition, Since Linux 5.19, EROFS has added EROFS over fscache to make use of fscache caching framework without explicit block devices, which is currently used by Dragonfly Nydus image service. There are some benefits such as massive blobs and on-demand loading. For more details, please look into this.

Single flattened device#

EROFS can still be mounted as a single flattened device even if the ondisk device table exists. It’s highly recommended that an ondisk device table is always included in the long term for related use cases.

Contents