EROFS Receives Some Useful Improvements With Linux 6.4
It sure doesn't feel like it's already been five years since Huawei announced EROFS as a read-only file-system initially designed for Android devices but has proven useful in the mainline Linux kernel to Linux users at large with interesting use-cases also coming up around containers and more. With the in-development Linux 6.4 kernel are yet more improvements to this read-only file-system.
EROFS with Linux 6.4 gains support for sub-page block support that is particularly useful in the AArch64 space where larger pages can be more common. Linux 6.4's EROFS also adds long xattr name prefixes functionality. There is also support for flattened block devices for multi-blob images to be attached into virtual machines.
The already-merged pull request from Gao Xiang explains:
As for the long xattr name prefixes code, Jingbo Xu of Alibaba explained in the prior patch series:
EROFS with Linux 6.4 gains support for sub-page block support that is particularly useful in the AArch64 space where larger pages can be more common. Linux 6.4's EROFS also adds long xattr name prefixes functionality. There is also support for flattened block devices for multi-blob images to be attached into virtual machines.
The already-merged pull request from Gao Xiang explains:
In this cycle, sub-page block support for uncompressed files is available. It's mainly used to enable golden 4k-block images on arm64 with 16/64k pages. In addition, end users could also use this feature to build a manifest to directly refer to golden tar data.
Besides, long xattr name prefix support is also introduced in this cycle to avoid too many xattrs with the same prefix (e.g. overlayfs xattrs). It's useful for erofs + overlayfs combination (like Composefs model): the image size is reduced by ~14% and runtime performance is also slightly improved.
As for the long xattr name prefixes code, Jingbo Xu of Alibaba explained in the prior patch series:
overlayfs uses xattrs to keep its own metadata. If such xattrs are heavily used, such as Composefs model [1], large amount of xattrs with diverse xattr values exist but only a few common xattr names are valid (trusted.overlay.redirect, trusted.overlay.digest, and maybe more in the future).
...
Let's introduce long xattr name prefixes now to fix this. They work similarly as the predefined name prefixes, except that long xattr name prefixes are user specified.
When a long xattr name prefix is used, the shared long xattr prefixes are stored in the packed or meta inode, while the remained trailing part of the xattr name apart from the long xattr name prefix will be stored in erofs_xattr_entry.e_name. e_name is empty if the xattr name matches exactly as the long xattr name prefix.
Add A Comment