Traduction des réflexions de Theodore Ts’o, créateur du système de fichiers Ext4, sur le développement d'ext4, du système de fichiers BcacheFS, du noyau Linux, du CoC, et des systèmes de fichiers en général :
Sur le développement d'ext4.
Chaque version du noyau ext4 est le fruit d'une collaboration de plus d'une douzaine de personnes. Actuellement, la majeure partie de mon temps est consacrée à la révision du code, à la réalisation de tests et à l'amélioration de l'application de test {kvm,gce,qemu,android}-xfstests. Je m'appuie également sur 2-3 autres développeurs travaillant chez SUSE et IBM, qui m'aident dans la révision du code.
Sur BcacheFS
Honnêtement, bcachefs n'est pas un projet entièrement isolé – par exemple, Kent a été l'auteur de 72% des patchs entre les versions du noyau 6.11 et 6.12, tandis que sur les 103 patchs pour ext4 durant la même période, j'étais l'auteur de exactement 0%. C'est parce que je crois fermement que la programmation est un sport d'équipe, et mon rôle en tant que leader technique est de permettre aux participants d'ext4 de donner le meilleur d'eux-mêmes pour améliorer le système de fichiers. Nous tenons des conférences hebdomadaires, et Derrick Wong, développeur senior de XFS et ancien mainteneur de XFS, y participe – et il est bien connu que je l'ai aidé sur des questions de test XFS, et Derrick m'a aidé sur diverses questions de test ext4, et a même examiné quelques patchs ext4. Nous collaborons ensemble, et c'est bénéfique.
Je laisse aux autres le soin de décider s'ils veulent faire confiance à quelqu'un qui est un programmateur isolé, qui peut très bien être plus talentueux que moi, mais je vais vous donner un indice – vous pouvez "tricher" en impliquant une équipe pour résoudre le problème. Il n'est pas nécessaire de tout faire seul. Bien sûr, cela nécessite de savoir comment éveiller le meilleur chez les autres, et vous devez travailler ensemble. Et un comportement poli dans les listes de diffusion ne fait pas de mal.
Sur le noyau, le CoC, les capacités et l'avenir d'ext4
Ext4 reçoit en effet certaines nouvelles fonctionnalités, mais ce sont celles que les entreprises sont prêtes à financer, car le retour sur investissement de la fonction a du sens en termes de coûts et de bénéfices. Par exemple, fscrypt et les répertoires sans distinction de casse étaient des fonctionnalités utiles pour Android et Chrome OS, et ont été financées, du moins en partie, par ces groupes de développeurs (Steam s'est également préoccupé de la réduction de casse et a soutenu l'un des ingénieurs). Nous souhaitons ajouter la prise en charge de l'écriture sans rupture (untorn), car cela améliorera les performances des bases de données sur des dispositifs de bloc émulés dans le cloud, où l'on peut garantir des enregistrements atomiques de 16k, ce qui permettra d'éliminer la double mise en mémoire tampon dans MySQL et PostgreSQL.
(En fait, Amazon et Google peuvent le faire dans leurs propres produits de SGBD, en supposant comment fonctionnent Amazon EBS et Google Persistent Disk, mais nous voulons le faire d'une manière plus générale, qui sera plus durable à long terme). C'est moins attrayant que des choses comme les reflinks, mais le retour sur investissement est beaucoup plus facile à justifier, à la fois parce que les coûts sont plus bas (moins de travail de développement, de test et de qualification pour le déploiement en entreprise) et parce que les avantages sont beaucoup plus faciles à évaluer quantitativement. Des choses comme « je peux économiser le coût des salaires de XX ingénieurs-programmeurs pendant cinq ans » sont beaucoup plus faciles à réaliser pour ce type de fonctions d'optimisation des performances.
À l'inverse, les reflinks sont amusants, mais je n'ai pas pu trouver de client prêt à payer les coûts de développement, ni d'entreprise qui pense que ses clients achèteraient plus de son produit s'ils ajoutaient des reflinks à ext4. Cela peut sembler horriblement corporate, mais il y a une histoire sur la façon dont les ingénieurs de ZFS ont commencé un projet à partir de zéro, sans demander l'autorisation de la direction ni obtenir de propositions du département des ventes, et ont présenté à Sun ce qui était en fait un fait accompli.
Cela semble bien, mais si l'on se souvient que Sun a finalement commencé à perdre de l'argent, jusqu'à devoir se vendre à une autre entreprise, et que l'organisation d'ingénierie soutenant ZFS n'existe plus. Environ à l'époque où ZFS a été annoncé, j'ai participé à une étude de toute l'entreprise pour déterminer s'il valait la peine d'investir dans des fonctionnalités de système de fichiers pour AIX et Linux - et nous avons conclu que non, le retour sur investissement était faible, et que les nouvelles fonctionnalités de système de fichiers n'attireraient pas plus de clients pour acheter du matériel, des logiciels ou des systèmes IBM. Peut-être qu'IBM a connu des temps difficiles, mais elle existe encore, tandis que Sun, elle, n'existe plus.
À peu près au même moment, des représentants de plusieurs entreprises Linux se sont réunis pour réfléchir à la manière dont Linux pourrait rivaliser avec ZFS. C'est lors de cette réunion que l'idée a été avancée que btrfs serait la réponse à long terme, tandis qu'ext4 serait une solution à court terme, capable de prendre en charge des éléments comme le redimensionnement en temps réel, des numéros de blocs 64 bits et d'autres fonctionnalités qui étaient présentes dans les anciennes systèmes Unix Legacy et absentes dans ext3.
Lors de cette réunion, on m'a demandé de définir ce qu'il faudrait pour créer un tout nouveau système de fichiers. J'ai effectué des recherches pour voir combien d'efforts étaient nécessaires pour créer des systèmes de fichiers tels que GPFS et JFS d'IBM, advfs de Digital, et j'ai évalué combien de temps Sun avait mis pour développer ZFS et amener ce système de fichiers à un état complètement prêt pour la production. La réponse que j'ai obtenue était d'environ 100 années-homme, avec une estimation basse à 50 années-homme et une estimation haute à 200 années-homme (mais cela concernait GPFS, qui était un système de fichiers de cluster et donc beaucoup plus complexe).
J'en ai parlé lors de la réunion, et un ingénieur senior d'Intel a déclaré : « Non, ne parlez pas de cela à la direction, car ils n'approuveront jamais le projet ! Dites-leur que btrfs sera prêt dans 18 mois ». Je laisse aux gens le soin de décider quand btrfs atteindra le statut de « prêt pour une utilisation en entreprise », en particulier pour ces nouvelles fonctionnalités avancées attrayantes qui devaient rivaliser avec ZFS, mais je ne pense pas qu'il soit discutable que cela ne s'est pas produit en 18 mois.
Et même avant que Sun ne se dissolve, de nombreuses entreprises ayant envoyé leurs représentants à la réunion ont refusé de laisser des ingénieurs participer au développement de btrfs, et cela, bien sûr, n'a pas aidé. Mais c'était probablement lié au fait que les entreprises sont des organisations rationnelles qui prennent leurs propres décisions sur le retour sur investissement, et le financement d'un nouveau système de fichiers n'avait pas autant de sens que de dire aux gens que Linux aurait une réponse à ZFS.
En regardant en arrière, on peut dire que, bien que ZFS ait effectivement eu des fonctionnalités vraiment intéressantes, cela n'a pas suffi à convaincre la majorité des utilisateurs de choisir Solaris plutôt que d'acheter des plateformes x86 beaucoup moins chères et de faire tourner Linux. Et au moment où Sun a décidé d'essayer la stratégie OpenSolaris et Solaris x86, il était trop tard. Les effets de réseau étaient énormes, et la stratégie x86 ne répondait pas à la question de savoir comment une seule entreprise, Sun, pouvait payer des salaires à tous les ingénieurs ultra talentueux travaillant sur Solaris. Acheter un serveur x86 à 5000 dollars n'offre pas une grande rentabilité comparativement à serveur SunFire E10k Sparc à 100000 dollars, que Sun appelait le « point » dans le « dot Com ».
L'essentiel est que l'ingénierie dans le monde réel est un compromis, et la réalité des affaires fait partie de ce compromis. Je ne m'excuse pas de préférer manger et de vouloir gagner suffisamment d'argent pour pouvoir prendre ma retraite un jour. Cela signifie, en retour, que je dois bien comprendre comment je profite à mon employeur, d'au moins dix fois mon salaire. Si je peux faire cela tout en continuant à travailler sur du code ouvert et en aidant d'autres entreprises à gagner de l'argent pour qu'elles soient prêtes à contribuer à ext4, eh bien, cela fait partie du défi et c'est pourquoi j'aime travailler sur du code ouvert.
Et, en revenant au Code de conduite, je dirai que presque tous les mainteneurs des systèmes de fichiers principaux ont soutenu le Code non pas pour des raisons libérales, mais parce que nous avons besoin de chaque ingénieur prêt à contribuer à notre projet. La plupart d'entre nous ont vu des gens refuser de travailler sous Linux et passer à d'autres systèmes d'exploitation (je connais une personne qui est passée à Windows et qui était un développeur clé du noyau Linux au IBM Linux Technology Center) ou travailler sur des projets internes, mais pas sur ceux nécessitant d'interagir avec la LKML, à cause de l'environnement toxique créé par quelques personnes sur la liste de diffusion.
Dans certains cas, les préoccupations étaient infondées ; par exemple, Linus a crié sur un développeur senior qui aurait vraiment dû savoir mieux et avec qui Linus avait déjà des relations établies. Le problème est que les nouveaux venus ne le savaient pas et avaient peur — « et si Linus m'humilie publiquement comme il l'a fait avec Steve », ne réalisant pas que cela ne se produirait pas en pratique. C'est pourquoi nous avons un CoC ; ce n'est pas pour nous, les ingénieurs seniors, mais pour soutenir les ingénieurs plus jeunes dans nos équipes que nous voulons former pour qu'ils nous remplacent à un moment donné lorsque le temps viendra de prendre notre retraite, ou si nous nous faisons renverser par un bus, ou si nous quittons ce monde de manière inattendue.
N'oubliez pas qu'il a fallu 50 à 100 années-homme pour créer un système de fichiers prêt à être utilisé en environnement d'entreprise. Nous avons besoin de tous les ingénieurs que nous pouvons attirer, et beaucoup d'entre nous font un travail supplémentaire pendant leur temps libre, parce que ça nous tient à cœur. Créer un système de fichiers de haute qualité est un travail d'équipe, et nous avons besoin de chaque ingénieur talentueux que nous pouvons obtenir. Même si un ingénieur est un programmeur dix fois meilleur, s'il finit par repousser un tas d'autres ingénieurs qui pourraient travailler sur des tests, l'optimisation de la performance, etc., cela ne vaut tout simplement pas la peine de laisser quelqu'un être un méchant.
Source : opennet.ru
