Ext4, XFS et les allocations retardées
Depuis quelques semaines, les débats sur l’allocation retardée des systèmes de fichiers modernes sont assez nombreux. Tout a été déclenché par le passage en mode par défaut d’ext4, le remplaçant rétro-compatible du système de fichier le plus utilisé sous Linux.
Les utilisateurs de poste de travail libre ayant suivi le mouvement ont eu quelques surprises, notamment de voir certains fichiers littéralement écrasés. Leur contenu n’existe plus et le fichier affiche une belle taille de zéro octet. Ce comportement ne peut arriver que sur les fichiers utilisés avant un arrêt brutal du poste.
Ces utilisateurs se sentent floués car, avec ext3, ce genre de comportement n’est tout simplement pas possible. Ici, avec leur poste nouvelle génération, ils sont susceptible d’avoir leur fichier de préférence Thunderbird remis à zéro : ce qui correspond fonctionnellement parlant à la perte de son compte de messagerie. Ou encore de perdre l’ensemble de leurs signet dans Firefox. Dans certains cas, c’est un document de travail bureautique entier qui a été perdu.
Du côté des développeurs de systèmes de fichier, la réponse a évolué. Ils connaissaient l’existence du problème, mais n’en réalisaient pas tout l’impact et toute la portée sur les utilisateurs.
Ils ont commencé par adopter l’attitude similaire à celle des développeurs XFS : ce n’est pas dans le sacro-saint standard POSIX, standard dont la dernière version a été publiée en 1995 et étant le dénominateur commun entre tous les systèmes de type UNIX.
Ensuite, la communauté ruant dans tous les brancards, ils ont affirmés que seules les applications non correctement codées étaient atteintes par ce problème. Ils ont conseillés à l’ensemble des développeurs d’application sous Linux d’utiliser l’appel système fsync, celui qui permet une synchronisation totale du contenu. Diverses réponses ont fusé suite à ce troll béant, notamment celle de Matthew Barret :
But you’re still arguing that applications should start using fsync(). I’m arguing that not only is this pointless (most of this code will never be “fixed”) but it’s also regressive. In most cases applications don’t want the guarantees that fsync() makes, [...]Appuyé par l’expérience personnelle de Linus Torvalds en user-land, sur Git :
The point here ? Sometimes those filesystem people who say “you must use fsync() to get well-defined semantics” are the same people who SCREWED IT UP SO DAMN BADLY THAT FSYNC ISN’T ACTUALLY REALISTICALLY USEABLE !Il a réussi à corriger plusieurs bugs de systèmes fichiers, notamment cifs, en vérifiant dans Git les codes d’erreurs de TOUS les appels systèmes.
La conclusion de toutes ces discussions reste à définir. De nombreux correctifs limitant les cas ont été poussé sur le noyau 2.6.30 et la prise de conscience réelle du problème est désormais claire dans l’esprit des développeurs de système de fichiers libres. De toutes façons, ils savent que s’ils ne font pas mieux qu’ext3, tous leurs efforts resteront lettre-morte. Toutes les performances et les nouvelles fonctionnalité ne servent strictement à rien sans une intégrité sans faille des données qui leur sont confiées.
Vous souhaitez reproduire cet article ?