Le 26 octobre, le développement de Linux 7.4-rc1 a intégré à ext4 une voie facultative d’E/S tamponnées fondée sur iomap, désactivée par défaut. Les résultats FIO attribués à Zhang Yi varient selon les écritures : un scénario de grandes écritures sans cache affiche un gain de 105 %, tandis que les petites écritures suivies chacune de fsync reculent de 15 %.
Pour activer cette voie, il faut utiliser l’option de montage buffered_iomap. ext4 peut revenir automatiquement à son chemin d’E/S d’origine lorsque c’est nécessaire. La modification concerne les E/S tamponnées des fichiers ordinaires, pas l’ensemble des opérations du système de fichiers.
Les résultats FIO dépendent du type d’écriture
Les mesures attribuées à Zhang Yi et rapportées le 28 octobre ont été réalisées dans une machine virtuelle à quatre cœurs avec un périphérique bloc adossé à la mémoire. Voici les cinq scénarios publiés, avec leur débit pour l’ancien chemin à buffer heads et pour iomap :
| Scénario FIO | ext4 avec buffer heads (MiB/s) | ext4 avec iomap (MiB/s) | Évolution rapportée |
| Écritures de 1 MiB en cache de pages | 4 295 | 5 780 | +35 % |
| Écritures de 64 KiB avec écriture différée en arrière-plan | 734 | 957 | +30 % |
| Écritures de 64 KiB sans cache | 415 | 698 | +68 % |
| Écritures de 1 MiB sans cache | 1 404 | 2 883 | +105 % |
Écritures de 1 KiB, avec fsync après chaque écriture | 0,71 | 0,60 | −15 % |
Les gains concernent ici des scénarios précis, notamment des écritures de grande taille. Le résultat des écritures de 1 KiB avec synchronisation après chaque écriture va dans l’autre sens. Ces chiffres décrivent les essais rapportés, pas une accélération générale d’ext4 sur tout matériel.
Les exclusions touchent le montage et certains inodes
Le pull request de Linux 7.4-rc1 énumère six cas incompatibles avec la nouvelle voie : la défragmentation en ligne, les données intégrées (inline data), fs-verity, fscrypt, les inodes sans extents et le mode data=journal. Le retour au chemin d’origine d’ext4 permet la reprise lorsque la voie iomap ne convient pas.
Ces cas ne relèvent pas tous du même réglage. data=journal est une option de montage. Le chiffrement, verity, les données intégrées et les extents correspondent à des attributs d’inode. L’interface FS_IOC_GETFLAGS permet de récupérer ces attributs. La défragmentation en ligne est une opération, et non un attribut permanent d’un inode. Pour examiner une configuration, il faut donc distinguer les options du montage des attributs des fichiers concernés.
Ce que change le mappage par plages
iomap demande au système de fichiers de décrire les plages qui relient les positions d’un fichier aux blocs de stockage. Des plages plus grandes peuvent répartir les appels de mappage sur davantage de données. Ce principe de conception aide à comprendre pourquoi certains essais de grandes écritures peuvent profiter de la nouvelle voie, sans garantir le même résultat pour chaque charge.
Le mode data=ordered est distinct de l’incompatibilité avec data=journal. Pour les inodes qui empruntent la voie iomap, le pull indique que data=ordered n’est pas utilisé. Ce mode ext4 écrit les blocs de données avant de valider les métadonnées associées. Le compte rendu du 28 octobre attribue aussi à Zhang Yi une réserve séparée sur les données de fin de fichier en cas de coupure d’alimentation.
