Quelques lignes de code accélèrent FAT32 jusqu’à 265 fois dans Linux 7.4
Une rustine de quelques lignes dans le pilote FAT du noyau remplace des allocations d’un cluster par une seule allocation multi-clusters, pour un gain mesuré jusqu’à 265 fois sur la pré-allocation. Fusionnée dans Linux 7.4, elle rappelle que FAT32 reste un système de fichiers de production sur les partitions EFI, les clés USB et l’embarqué.
Fin octobre 2026. La rustine du développeur Matheus Alves de Almeida est fusionnée dans Linux 7.4 via la pull request non-MM d’Andrew Morton. 29 octobre 2026. Phoronix relaie des mesures spectaculaires : jusqu’à 265 fois plus rapide sur la pré-allocation de fichiers FAT32. Quelques lignes de code suffisent à expliquer le gain. FAT32 n’est pas mort — il porte encore la partition EFI de presque toutes les machines.
Le goulot : une allocation cluster par cluster
Le chemin incriminé est celui de FALLOC_FL_KEEP_SIZE, un drapeau de fallocate qui pré-alloue de l’espace disque à un fichier sans en changer la taille apparente. Les hyperviseurs s’en servent pour les images QEMU, les bases de données pour réserver de l’espace, les clients de téléchargement pour éviter la fragmentation.
Sous FAT32, l’implémentation historique découpait cette pré-allocation en une allocation d’un cluster à la fois. Pour un gros fichier, cela se traduit par des milliers d’appels individuels, chacun avec sa propre comptabilité, ses verrous et ses écritures de métadonnées. La rustine change cela : au lieu d’allouer un cluster par appel, elle alloue plusieurs clusters en un seul appel.
# Pré-allouer 1 Go sans changer la taille apparente du fichier (FALLOC_FL_KEEP_SIZE)
fallocate --keep-size -l 1G image.imgSous le capot, FAT32 tient sa table d’allocation — la File Allocation Table — comme une liste chaînée : chaque cluster pointe vers le suivant. Allouer un fichier, c’est écrire une chaîne de pointeurs dans cette table, et chaque écriture oblige à relire et synchroniser la région concernée. En découpant la pré-allocation en appels d’un cluster, l’ancien code multipliait ces accès à la table pour rien. La rustine regroupe la chaîne en une seule passe, ce qui explique l’ampleur du gain sur un chemin qui semblait anodin.
Le résultat est un gain de jusqu’à 265 fois sur les micro-benchmarks publiés par le développeur. La correction touche « quelques lignes de code » — un bon rappel que les chemins hérités peuvent cacher des goulots énormes.
FAT32 n’est pas un système de fichiers mort
Beaucoup considèrent FAT32 comme une relique. C’est une erreur. Le format reste incontournable dans trois cas précis.
La partition EFI System Partition (ESP), qui porte le chargeur de démarrage UEFI, est en FAT32 sur la quasi-totalité des machines — Windows, Linux et macOS confondus. Les clés USB et les cartes SD continuent d’être formatées en FAT32 pour la compatibilité avec les téléviseurs, les consoles, les appareils photo et les autoradios. Enfin, les systèmes embarqués et les firmwares l’utilisent pour sa simplicité d’implémentation.
Le système a des limites connues : 4 Go par fichier, 8 To par volume au maximum avec des clusters de 32 Ko, et aucune journalisation — une coupure de courant peut corrompre des métadonnées. Mais ces limites n’ont pas fait disparaître l’usage. Elles ont simplement figé les cas d’usage sur des médias de petite capacité ou des partitions système.
D’où vient FAT32, et pourquoi il ne partira pas
FAT32 n’est pas un choix, c’est un héritage devenu standard. Le format est apparu avec Windows 95 OSR2 en août 1996, pour dépasser les partitions de 2 Go que FAT16 plafonnait. Sa limite de 4 Go par fichier vient d’un champ de taille sur 32 bits dans l’entrée de répertoire : une contrainte gravée dans le format lui-même.
Le successeur logique, exFAT (2006), lève cette limite, mais son adoption est inégale. Les lecteurs de cartes, les téléviseurs et les autoradios anciens ne le lisent pas toujours. La norme UEFI impose par ailleurs la prise en charge de FAT32 pour la partition ESP : c’est le point d’ancrage qui rend le format indéboulonnable sur les machines neuves, quelle que soit la distribution. La spécification des cartes SD raconte la même histoire : FAT32 pour les cartes jusqu’à 32 Go (SDHC), exFAT au-delà (SDXC).
Le résultat est un format qui cumule des usages figés et une contrainte structurelle : on ne peut pas le retirer sans casser l’amorçage UEFI, la compatibilité des médias amovibles et une partie de l’embarqué. C’est précisément parce que FAT32 est incontournable que son chemin d’allocation méritait d’être optimisé.
Ce que la rustine change, et ce qu’elle ne change pas
Il faut être précis sur l’ampleur du gain. La rustine accélère le chemin de pré-allocation — pas l’écriture effective des données. Un transfert de fichiers classique vers une clé USB ne verra pas un gain de 265 fois : c’est l’opération fallocate --keep-size qui en profite, quand on réserve de l’espace en amont.
Le contexte de Linux 7.4 donne une mesure de l’état du sous-système FAT. Le même cycle a vu le pilote NTFS3 durci contre les volumes corrompus ou malveillants, et F2FS gagner des multi-grain timestamps en opt-in. Le noyau continue d’investir dans les systèmes de fichiers de compatibilité, non par nostalgie, mais parce qu’ils sont porteurs : la partition EFI seule justifie que le pilote FAT reste maintenu et performant.
La leçon de fond dépasse FAT32. Un chemin de code peu regardé — ici, l’allocation de clusters — peut accumuler une inefficacité énorme simplement parce que personne ne l’a re-mesuré depuis des années. C’est l’argument le plus fort en faveur des micro-benchmarks ciblés sur les chemins froids.
Ce que cela dit de la maintenance du noyau
La rustine est entrée par la pull request non-MM d’Andrew Morton, l’une des voies par lesquelles les correctifs de systèmes de fichiers et de mémoire rejoignent le noyau. Ce détail compte : il montre que Linux traite les systèmes de fichiers de compatibilité comme des citoyens de première classe, au même titre que les pilotes matériels récents.
Le cycle 7.4 illustre ce double mouvement. D’un côté, des gains de performance sur des chemins historiques — ici FAT32, mais aussi un allocateur mémoire de boot passé de 268 secondes à environ 50 millisecondes. De l’autre, du durcissement : le pilote NTFS3 renforcé contre les volumes corrompus ou malveillants. Le noyau n’arbitre pas entre performance et sécurité : il avance sur les deux fronts, y compris là où personne ne regarde.
Pour un opérateur de systèmes, la conclusion est simple : ces chemins ne sont pas abandonnés, et les mises à niveau du noyau apportent des gains réels — y compris sur des composants que l’on croyait figés depuis vingt ans. La leçon de sobriété vaut aussi pour l’ingénierie : le gain de 265 fois ne vient pas d’une réécriture, mais d’une mesure et d’une correction ciblée.
Verdict
Si vous pré-allouez des fichiers sur des médias FAT32 — images de machines virtuelles, gros fichiers écrits sur carte SD ou clé USB — le noyau 7.4 vous apporte un gain réel, et il n’y a rien à faire : la correction est déjà fusionnée. Pour l’usage courant, aucune action : le transfert de fichiers et la lecture ne changent pas, et FAT32 reste ce qu’il était — simple, non journalisé, limité à 4 Go par fichier. Si vous concevez des systèmes embarqués ou des images système, retenez la vraie leçon : avant de réécrire un chemin de code hérité, mesurez-le. Quelques lignes peuvent valoir deux ordres de grandeur. Et si vous maintenez un noyau de distribution, ce genre de correctif est exactement celui que les backports de performance ont tendance à oublier : vérifiez qu’il ne soit pas écarté au profit des seuls correctifs de sécurité.