Es fühlt sich sicher nicht so an, als wäre es schon fünf Jahre her, seit Huawei EROFS als schreibgeschütztes Dateisystem angekündigt hat, das ursprünglich für Android-Geräte entwickelt wurde, sich aber im Mainline-Linux-Kernel für Linux-Benutzer insgesamt als nützlich erwiesen hat, wobei auch interessante Anwendungsfälle kommen werden um Container herum und mehr. Mit dem in Entwicklung befindlichen Linux 6.4-Kernel gibt es noch weitere Verbesserungen an diesem Nur-Lese-Dateisystem.
EROFS mit Linux 6.4 erhält Unterstützung für die Unterstützung von Unterseitenblöcken, die besonders im AArch64-Bereich nützlich ist, wo größere Seiten häufiger vorkommen können. EROFS von Linux 6.4 fügt auch lange xattr-Namenspräfixe hinzu. Es gibt auch Unterstützung für abgeflachte Blockgeräte für Multi-Blob-Images, die an virtuelle Maschinen angehängt werden können.
Der bereits zusammengeführte Pull Request von Gao Xiang erklärt:
In diesem Zyklus ist die Blockunterstützung von Unterseiten für unkomprimierte Dateien verfügbar. Es wird hauptsächlich verwendet, um goldene 4k-Block-Bilder auf arm64 mit 16/64k-Seiten zu ermöglichen. Darüber hinaus könnten Endbenutzer diese Funktion auch verwenden, um ein Manifest zu erstellen, um direkt auf Golden-Tar-Daten zu verweisen.
Außerdem wird in diesem Zyklus auch Unterstützung für lange xattr-Namenspräfixe eingeführt, um zu viele xattrs mit demselben Präfix zu vermeiden (z. B. overlayfs xattrs). Es ist nützlich für die Kombination von erofs + overlayfs (wie das Modell von Composefs): Die Bildgröße wird um ~14 % reduziert und die Laufzeitleistung wird ebenfalls leicht verbessert.
Was den Code für lange xattr-Namenspräfixe betrifft, erklärte Jingbo Xu von Alibaba im vorherigen Patch-Serie:
overlayfs verwendet xattrs, um seine eigenen Metadaten zu behalten. Wenn solche xattrs stark genutzt werden, wie zum Beispiel das Modell von Composefs [1], gibt es eine große Menge von xattrs mit unterschiedlichen xattr-Werten, aber nur wenige gebräuchliche xattr-Namen sind gültig (trusted.overlay.redirect, trusted.overlay.digest und vielleicht mehr in die Zukunft).
…
Lassen Sie uns jetzt lange xattr-Namenspräfixe einführen, um dies zu beheben. Sie funktionieren ähnlich wie die vordefinierten Namenspräfixe, außer dass lange xattr-Namenspräfixe vom Benutzer angegeben werden.Wenn ein langes xattr-Namenspräfix verwendet wird, werden die gemeinsam genutzten langen xattr-Präfixe im gepackten oder Meta-Inode gespeichert, während der verbleibende nachlaufende Teil des xattr-Namens abgesehen vom langen xattr-Namenspräfix in erofs_xattr_entry.e_name gespeichert wird. e_name ist leer, wenn der xattr-Name genau mit dem langen xattr-Namenspräfix übereinstimmt.
