NFS et ext3...

J'ai un serveur NFS avec le dernier noyau pour debian woody, qui est un 2.4.18, il marche très bien. J'en ai aussi un autre, avec un noyau 2.4.18 aussi, qui n'a que des clients Linux, par ailleurs en plus grand nombre, et qui marche très bien. Tout est dans l'interaction avec des clients Sun... Enfin on n'est pas encore retombé au niveau du serveur NFS qui accompagnait le noyau 2.0 : l'utilisation de clients Sun finissait par causer la corruption de fichiers, y compris s'ils n'étaient accédés qu'en lecture ! Cela dit, avec ou sans bug dans le NFS, quand les Sun que j'ai au boulot seront enfin morts de vieillesse (ils prennent leur temps, les charognes), ça me fera des soucis en moins. J'ai un autre poste qui fonctionne avec un 2.4.19 sans aucun problème avec ext3 (ce bug, reproductible facilement ?) Je ne sais pas. En fait, au moment où je m'apprêtais à installer le 2.4.20 sur les serveurs, est sortie la news concernant le bug de ext3fs introduit dans cette version. Un des commentaires faisait référence à un autre bug répertorié pour le 2.4.19 et pas corrigé avant la sortie du 2.4.20. Je ne connais pas trop les détails, je me suis juste dit qu'il serait peut-être aussi prudent d'attendre le 2.4.21 avant de voir à changer mon 2.4.18... Cela dit, pour ce qui est d'arriver à prendre en défaut la journalisation avec le 2.4.19, je ne sais pas si ça a un lien avec le bug sus-cité, mais il suffit de lâcher des étudiants sur les machines (j'ai des postes clients en 2.4.19) et il finissent par arriver à péter complètement un système de fichiers... Le "stress", et donc le risque, est moins important pour le serveur, mais les données sont plus critiques aussi, donc dans le doute, ça n'encourage pas à changer de noyau. Ceci étant précisé, il ne me semble pas que ce Marcello puisse être jugé responsable des bugs. Non bien sûr, mais c'est peut-être bien grâce à Alan Cox s'il passait moins de bugs critiques avant...

« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone