Un problème sérieux est récemment apparu dans OpenZFS 2.2.0, implémenté dans des systèmes d'exploitation tels que FreeBSD 14. La nouvelle fonctionnalité, introduite il y a un mois, s'appelle « clonage de blocs » et vise à optimiser la gestion des données. Cependant, un bug critique, identifié par l'équipe Gentoo et signalé comme bug #15526, a conduit à la sortie immédiate d'OpenZFS 2.2.1, qui désactive temporairement cette fonctionnalité.
Cet incident soulève des inquiétudes quant à la fiabilité d'OpenZFS, connu pour sa robustesse et l'intégrité de ses données. De plus, pour les systèmes comme FreeBSD 14, qui incluent cette version d'OpenZFS, la prudence est de mise. L'expert BSD Colin Percival a souligné sur Twitter que la fonctionnalité de « clonage de bloc » est désactivée par défaut dans FreeBSD 14 et a mis en garde contre son activation pour éviter la perte de données.
Le bogue se manifeste par une corruption de fichiers : les fichiers copiés affichent une combinaison de zéros et de blocs de données qui semblent être codés en Base64. Il est intéressant de noter que les vérifications de l'état du système de fichiers ne détectent pas le problème, ce qui nécessite une attention particulière.
La nature du bug semble être liée à des circonstances spécifiques et rares. Bronek Kozicki a expliqué sur GitHub que le bug pouvait survenir lors de l'écriture asynchrone d'un fichier, si à ce moment précis la partie du fichier qui est encore en cours d'écriture est lue. Cela peut conduire à des données corrompues, un problème difficile à détecter sans comparer les sommes de contrôle.
Les développeurs ont identifié un problème lié aux nœuds ZFS et à leur gestion, qui peut être un bug caché plus ancien. Le bug est devenu plus visible avec l'introduction de la nouvelle fonctionnalité de clonage de blocs, en particulier dans les systèmes multicœurs.
Pour les utilisateurs Linux, il semble que le bug soit également lié à la version de coreutils utilisée, notamment les versions ultérieures à 9.x. Il n'est pas encore clair si Ubuntu 23.10 a activé cette fonctionnalité par défaut dans sa prise en charge ZFS récemment revenue mais encore expérimentale.
OpenZFS 2.2.2 devrait arriver bientôt pour résoudre ces problèmes. En attendant, la communauté est encouragée à maintenir une approche prudente et à envisager des sauvegardes sur d'autres systèmes de fichiers pour garantir la sécurité des données.
Nous avons déjà mentionné le travail de l'expert BSD Colin Percival, mais quiconque a déjà installé cette version « ground zero » devrait tenir compte de son avertissement sur Twitter X : « Le code ZFS de FreeBSD 14 prend en charge le « clonage de blocs ». Ceci est désactivé par défaut. N'ACTIVEZ PAS CETTE FONCTION SI VOUS NE VOULEZ PAS PERDRE DE DONNÉES.
Le code ZFS de FreeBSD 14 prend en charge le « clonage de blocs ». Ceci est désactivé par défaut.
N'ACTIVEZ PAS CETTE FONCTION SAUF SI VOUS VOULEZ PERDRE DES DONNÉES. https://t.co/Embps7Te4e
– Colin Percival (@cperciva) 23 novembre 2023
Au moment de la rédaction de cet article, on ne sait pas exactement quelle en est la cause. Il semble qu’il s’agisse d’une combinaison de circonstances extrêmement spécifique (et donc improbable), ce qui signifie que cela ne se produit presque jamais, comme l’explique Bronek Kozicki sur GitHub :
Il est nécessaire de comprendre le mécanisme à l’origine de la corruption. Il se peut qu’il soit présent depuis une décennie et ne cause des problèmes que dans des scénarios très spécifiques, qui ne se produisent normalement pas.
À moins que vous puissiez adapter votre mécanisme de sauvegarde aux conditions décrites ci-dessous, il est très peu probable que vous en ayez été affecté.
- Un fichier est en cours d'écriture (généralement de manière asynchrone – ce qui signifie que l'écriture n'est pas terminée au moment où le processus d'écriture « pense » qu'il l'est)
- Pendant que ZFS continue d'écrire des données, la partie modifiée du fichier est en cours de lecture. Le même moment signifie « atteindre une fenêtre de temps très spécifique », mesurée en microsecondes (un millionième de seconde).
- S'il est lu à ce moment très précis, le lecteur verra des zéros là où les données écrites sont en réalité autre chose.
- Si le lecteur stocke ensuite les zéros mal lus ailleurs, c'est là que les données sont corrompues. L'un des chasseurs de bogues a écrit un script, reproducteur.sh, qui cible les volumes ZFS et vérifie si les fichiers sont corrompus. L'un des problèmes liés à cette question est qu'il n'existe aucun moyen d'écrire un programme capable de signaler si un fichier a été corrompu ou non en inspectant son contenu : il est parfaitement normal que certains types de fichiers contiennent de longues séquences de zéros. La seule façon d'en être sûr est de comparer les sommes de contrôle avant et après les opérations de copie. Ainsi, les utilisateurs inquiets qui ne disposent pas de sauvegardes sur d'autres types de systèmes de fichiers ne peuvent pas facilement le savoir. L'outil intégré d'OpenZFS pour vérifier la validité des pools de stockage ne peut pas détecter le problème.
Un correctif possible est ouvert et l'enquête semble avoir découvert un bug sous-jacent différent et préexistant, qui aurait pu être présent dès 2013. Le bug affecte les dnodes ZFS et la logique de la façon dont le code vérifie si un dnode est « sale » ou non, ce qui détermine s'il doit le télécharger : synchroniser les modifications apportées au disque.
Il est possible que cette cause unique ait été profondément cachée et donc très peu susceptible d’être ciblée. Malheureusement, la nouvelle fonctionnalité de copie plus rapide signifiait que ce qui était un bug qui ne corrompait les données qu'une fois sur des dizaines de millions de copies de fichiers devenait soudainement plus probable, en particulier sur les machines dotées de nombreux cœurs de processeur utilisés simultanément.
Pour les utilisateurs de Linux, une condition supplémentaire semble être que le système d'exploitation dispose d'une version récente du package coreutils – supérieure à la version 9.x. Il s'agit de l'outil qui fournit la fonctionnalité de la commande cp. Jusqu'à présent, nous n'avons pas pu vérifier si Ubuntu 23.10 a la fonctionnalité de clonage de blocs activée par défaut dans sa prise en charge récemment renvoyée (mais toujours expérimentale) pour l'installation sur ZFS, mais au moins un commentaire sur le bogue d'origine vient de quelqu'un qui je l'ai reproduit sur Ubuntu.
Il semble très probable qu'OpenZFS 2.2.1, qui désactive simplement le clonage de blocs, soit rapidement suivi d'une version 2.2.2 pour corriger le traitement sous-jacent des dnodes.
