Il ne semble certainement pas que cela fait déjà cinq ans que Huawei a annoncé EROFS comme un système de fichiers en lecture seule initialement conçu pour les appareils Android, mais s’est avéré utile dans le noyau Linux principal pour les utilisateurs Linux en général avec des cas d’utilisation intéressants également à venir autour des conteneurs et plus encore. Avec le noyau Linux 6.4 en développement, d’autres améliorations ont été apportées à ce système de fichiers en lecture seule.
EROFS avec Linux 6.4 prend en charge la prise en charge des blocs de sous-pages, ce qui est particulièrement utile dans l’espace AArch64 où les pages plus grandes peuvent être plus courantes. EROFS de Linux 6.4 ajoute également une fonctionnalité de préfixes de noms longs xattr. Il existe également une prise en charge des périphériques de bloc aplatis pour les images multi-blob à attacher aux machines virtuelles.
La demande d’extraction déjà fusionnée de Gao Xiang explique :
Dans ce cycle, la prise en charge des blocs de sous-pages pour les fichiers non compressés est disponible. Il est principalement utilisé pour activer les images dorées en bloc 4k sur arm64 avec des pages 16/64k. En outre, les utilisateurs finaux peuvent également utiliser cette fonctionnalité pour créer un manifeste afin de se référer directement aux données Golden Tar.
En outre, la prise en charge du préfixe de nom long xattr est également introduite dans ce cycle pour éviter trop de xattrs avec le même préfixe (par exemple, overlayfs xattrs). C’est utile pour la combinaison erofs + overlayfs (comme le modèle Composefs) : la taille de l’image est réduite d’environ 14 % et les performances d’exécution sont également légèrement améliorées.
En ce qui concerne le code des préfixes de noms longs xattr, Jingbo Xu d’Alibaba a expliqué dans le précédent série de correctifs :
overlayfs utilise xattrs pour conserver ses propres métadonnées. Si de tels xattrs sont fortement utilisés, comme le modèle Composefs [1], il existe une grande quantité de xattr avec diverses valeurs de xattr mais seuls quelques noms de xattr communs sont valides (trusted.overlay.redirect, trusted.overlay.digest, et peut-être plus dans l’avenir).
…
Introduisons maintenant les longs préfixes de nom xattr pour résoudre ce problème. Ils fonctionnent de la même manière que les préfixes de nom prédéfinis, sauf que les préfixes de nom xattr longs sont spécifiés par l’utilisateur.Lorsqu’un préfixe de nom long xattr est utilisé, les préfixes longs xattr partagés sont stockés dans l’inode compressé ou méta, tandis que la partie restante du nom xattr, à l’exception du préfixe long du nom xattr, sera stockée dans erofs_xattr_entry.e_name. e_name est vide si le nom xattr correspond exactement au préfixe long du nom xattr.
