La demande Btrfs pour Linux 7.3 annonce plusieurs gains importants, chacun lié à un chemin ou une charge précise. Elle modifie aussi le cache d’espace libre et les montages de secours, à examiner indépendamment des performances.
Quatre résultats, avec des références différentes
La demande du 19 août de David Sterba décrit l’usage d’un tampon intermédiaire iomap pour les E/S directes, à la place d’un repli vers les E/S avec cache. Le débit annoncé passe d’environ 50 % à 95 % du maximum théorique dans le cas concerné. Cela représente environ 1,9 fois le débit, pas 95 % de mieux pour toute opération Btrfs.
Les autres résultats concernent le suivi des buffers de métadonnées inhibés, la suppression d’un délai d’un jiffy pendant des écritures de journal concurrentes en mode non-SSD, et l’évitement de la recherche de trous pendant un fsync complet sur des fichiers sans trous mais riches en extents. Les gains annoncés sont respectivement d’environ 3×, 5× en débit et 5× sur la durée de l’opération ciblée. L’exemple fsync porte sur des durées en microsecondes.
Ce sont des résultats des développeurs, pas des mesures PeopleAreGeek. Multiplier ces chiffres assemblerait des opérations différentes en un benchmark qui n’a pas été effectué.
Passer du débit au temps écoulé
Un calcul original éclaire le chiffre des E/S directes. Supposons un plafond de 1 000 Mo/s et un transfert fixe de 1 000 Mo sans autre travail. À 50 % du plafond, il dure deux secondes ; à 95 %, environ 1,05 seconde, soit 47 % de temps en moins.
Si l’application passe aussi trois secondes inchangées à calculer, son total passe de cinq secondes à environ 4,05 secondes : 19 % de réduction. Ces nombres fictifs montrent pourquoi un gain sur le stockage ne prédit pas celui de l’application entière. L’illustration représente cette différence.
Vérifier séparément cache et récupération
La demande désactive par défaut le cache d’espace libre v1. Elle précise que les systèmes de fichiers concernés restent utilisables, parfois plus lentement faute de cache des groupes de blocs. L’absence du drapeau free-space-tree ne prouve pas à elle seule que le cache v1 est actif : le cache peut aussi être désactivé.
La documentation des options de montage décrit activation de v2 et nettoyage. Activer v2 efface v1 au premier montage ; l’ancienne consigne imposant ensuite un nettoyage hors ligne supplémentaire était trompeuse. Examinez état réel, options de montage et compatibilité des anciens noyaux de secours avant toute conversion.
Vérifiez également les scripts de récupération : usebackuproot seul disparaît et rescue=usebackuproot impose un montage en lecture seule. Pour évaluer les gains, conservez une charge identique et mesurez chemin d’E/S, latence et intégrité sur un volume de test.
Revue du 8 septembre : annonces et documents techniques vérifiés, évolutions ajoutées et illustration explicative reprise.