La deuxième interview d'Eduard Shishkin, développeur du système de fichiers Reiser4, a été publiée.
Pour commencer, veuillez rappeler aux lecteurs où et pour qui vous travaillez.
Je travaille en tant qu'architecte de stockage principal chez Huawei Technologies, centre de recherche allemand. Dans le département de virtualisation, je m'occupe de différents aspects du stockage de données. Mes activités ne sont pas liées à un système d'exploitation spécifique.
Êtes-vous actuellement engagé dans la branche principale du noyau ?
Très rarement, et seulement si mon employeur l'exige. La dernière fois, c'était il y a environ trois ans, j'ai envoyé des correctifs pour augmenter le débit du stockage partagé sur les hôtes utilisant le protocole 9p (un autre nom pour cette activité est VirtFS). Une remarque importante doit être faite ici : même si je travaille avec Linux depuis longtemps, je n'en ai jamais été fan, c'est-à-dire que je « respire uniformément », comme pour tout le reste. En particulier, si je constate un défaut, je peux le signaler au maximum une fois. Et pour que vous puissiez ensuite suivre quelqu'un et le persuader, cela n'arrivera pas.
Je me souviens de la dernière fois, il y a dix ans, vous aviez été assez critique à l'égard du style de développement du noyau. De votre point de vue (ou peut-être de celui de votre entreprise), quelque chose a-t-il changé, la communauté est-elle devenue plus réactive ou non ? Si non, à votre avis, à qui la faute ?
Je n'ai jamais vu de changements pour le mieux. Le principal problème de la communauté est le remplacement de la science par les technologies politiques, les relations personnelles, l’opinion majoritaire, le populisme, les conseils des « voix intérieures », les compromis pourris, tout autre chose que la science. L’informatique, quoi qu’on en dise, est avant tout une science exacte. Et si quelqu'un commence à proclamer sa propre valeur pour 2x2, différente de 4, sous le drapeau « à la manière de Linux », ou sous un autre drapeau, alors il est peu probable que cela apporte autre chose que du mal.
Tous les problèmes sont dus avant tout à l’incompétence et au manque d’éducation de ceux qui prennent les décisions. Si un manager est incompétent, il n'est pas en mesure de prendre une décision objective et adéquate. S'il est également inculte, il ne parvient pas à trouver un spécialiste compétent qui lui donnera les bons conseils. Avec une forte probabilité, le choix reviendra à un escroc qui dit « des choses apparemment correctes ». Un environnement corrompu se développe toujours autour de dirigeants solitaires et incompétents. De plus, l’histoire ne connaît pas d’exception à cet égard, et la communauté en est la confirmation la plus claire.
Comment évaluez-vous les progrès du développement de Btrfs ? Ce FS a-t-il éliminé les maladies infantiles ? Comment le positionnez-vous pour vous-même - en tant que FS « pour la maison » ou également pour un usage professionnel ?
Je ne m'en suis pas débarrassé. Tout ce que j’évoquais il y a 11 ans est toujours d’actualité aujourd’hui. L'un des problèmes de Btrfs qui le rend inadapté à des besoins sérieux est le problème de l'espace libre. Je ne parle même pas du fait qu'il est demandé à l'utilisateur de se rendre au magasin pour un nouveau disque dans des situations où n'importe quel autre FS afficherait beaucoup d'espace libre sur la partition. L'incapacité de terminer une opération sur un volume logique en raison du manque d'espace libre n'est pas non plus la pire des choses. Le pire, c'est qu'un utilisateur non privilégié peut presque toujours, contourner les quotas de disque, priver tout le monde d'espace libre en un temps assez court.
Cela ressemble à ceci (testé pour le noyau Linux 5.12). Un script est lancé sur un système fraîchement installé, qui crée en boucle des fichiers portant certains noms dans le répertoire personnel, y écrit des données à certains décalages, puis supprime ces fichiers. Après une minute d'exécution de ce script, rien d'inhabituel ne se produit. Au bout de cinq minutes, la part d'espace occupé sur la partition augmente légèrement. Au bout de deux à trois heures, elle atteint 50 % (avec une valeur initiale de 15 %). Et après cinq ou six heures de travail, le script plante avec l'erreur « il n'y a pas d'espace libre sur la partition ». Après cela, vous ne pouvez même plus écrire un fichier 4K sur votre partition.
Une situation intéressante se produit : vous avez fini par ne rien écrire sur la partition et tout l'espace libre (environ 85 %) a disparu quelque part. L'analyse d'une section soumise à une telle attaque révélera de nombreux nœuds d'arbre contenant un seul élément (un objet équipé d'une clé), de plusieurs octets. C'est-à-dire que le contenu qui occupait auparavant 15 % de l'espace disque s'est avéré être uniformément « réparti » sur toute la partition, de sorte qu'il n'y a nulle part où écrire un nouveau fichier, car sa clé est plus grande que toutes celles existantes, et la clé libre les blocs sur la partition sont épuisés.
De plus, tout cela se produit déjà sur la configuration de base de Btrfs (sans instantanés, sous-volumes, etc.), et peu importe la façon dont vous décidez de stocker les corps de fichiers dans ce FS (en tant que « fragments » dans une arborescence ou en tant qu'extensions). de blocs non formatés) - le résultat final sera le même.
Vous ne pourrez pas soumettre d'autres systèmes de fichiers en amont à une telle attaque (peu importe ce qu'ils vous disent). J'ai expliqué la cause du problème il y a longtemps : il s'agit d'une perversion complète du concept B-tree dans Btrfs, qui permet de le dégénérer spontanément ou intentionnellement. En particulier, sous certaines charges, votre système de fichiers « s'effondrera » continuellement pendant le fonctionnement, sans aide extérieure. Il est clair que toutes sortes de processus d'arrière-plan « pressants » ne sauveront la situation que sur des postes de travail individuels.
Sur les serveurs collectifs, un attaquant pourra toujours « devancer » eux. L'administrateur système ne sera même pas en mesure de déterminer qui l'a exactement intimidé. Le moyen le plus rapide de résoudre ce problème dans Btrfs est de restaurer la structure d'un arbre B normal, c'est-à-dire repenser le format du disque et réécrire des parties importantes du code Btrfs. Cela prendra 8 à 10 ans, débogage compris, à condition que les développeurs suivent strictement les articles originaux sur les algorithmes et les structures de données concernés, et ne jouent pas au jeu du « téléphone cassé », comme il est d'usage (et encouragé) dans le système « Linux ». chemin".
Ici, il faut aussi ajouter le temps nécessaire aux développeurs pour comprendre tout cela. C'est là que ça devient plus difficile. De toute façon, 10 ans n’ont pas suffi pour qu’ils comprennent. Eh bien, d’ici là, vous ne pouvez pas espérer de miracle. Cela ne se produira pas sous la forme d’une option de montage « dont vous et moi ne connaissions pas l’existence » ou sous la forme d’un correctif qui serait « juste une question de business » à préparer. Pour chacune de ces « solutions » hâtives, je présenterai un nouveau scénario de dégénérescence. Les B-trees sont un de mes sujets favoris, et je dois dire que ces structures ne tolèrent pas de libertés avec elles-mêmes !
Comment puis-je positionner Btrfs pour moi-même ? Comme quelque chose qui ne peut absolument pas être appelé un système de fichiers, et encore moins utilisé. Car, par définition, le FS est un sous-système du système d'exploitation chargé de la gestion efficace de la ressource « espace disque », ce que l'on ne voit pas dans le cas de Btrfs. Eh bien, imaginez que vous soyez venu au magasin pour acheter une montre afin de ne pas être en retard au travail, et qu'au lieu d'une montre, ils vous ont vendu un gril électrique avec une minuterie pour un maximum de 30 minutes. La situation avec Btrfs est donc encore pire.
En parcourant les listes de diffusion, je tombe souvent sur l'affirmation selon laquelle la gestion efficace de l'espace disque n'est plus pertinente en raison du faible coût des disques. C’est complètement absurde. Sans un gestionnaire d'espace disque efficace, le système d'exploitation deviendra vulnérable et inutilisable. Quelle que soit la capacité des disques de votre machine.
Je voudrais demander des commentaires sur l'arrêt du support Btrfs dans RHEL.
Il n’y a rien de particulier à commenter ici, tout est très clair. Ils l’avaient également comme « aperçu technologique ». Donc, je n’ai pas parcouru cet « aperçu ». Ne laissez pas cette étiquette pendre éternellement ! Mais ils ne peuvent pas lancer un produit de conception défectueuse avec un support complet. RHEL est une entreprise, c'est-à-dire des relations marchandise-argent prescrites. Red Hat ne peut pas intimider les utilisateurs comme ils le font sur la liste de diffusion Btrfs. Imaginez la situation : un client qui a payé son argent durement gagné pour le disque et vous aussi pour l'assistance, veut comprendre où est passé son espace disque alors qu'il n'a rien écrit. Que vas-tu lui répondre à cela ?
Plus loin. Les clients de Red Hat comprennent de grandes banques et bourses bien connues. Imaginez ce qui se passerait s'ils étaient soumis à des attaques DoS basées sur la vulnérabilité mentionnée dans Btrfs. Selon vous, qui est responsable de cela ? À ceux qui s’apprêtent à pointer du doigt la ligne de la licence GPL, où il est écrit que l’auteur n’est responsable de rien, je dirai tout de suite : « cachez-le ! » Red Hat répondra, et de telle manière que cela ne semblera pas suffisant ! Mais je sais que Red Hat n'est pas confronté à ce genre de problème, compte tenu de son équipe d'ingénieurs QA particulièrement solide avec laquelle j'ai eu l'occasion de travailler en étroite collaboration à mon époque.
Pourquoi certaines entreprises continuent-elles à prendre en charge Btrfs dans leurs produits d'entreprise ?
Veuillez noter que le préfixe « entreprise » dans le nom du produit ne veut pas dire grand-chose. L'entreprise est une mesure de responsabilité ancrée dans la relation contractuelle avec le client. Je ne connais qu'une seule entreprise basée sur GNU/Linux : RHEL. Tout le reste, de mon point de vue, est présenté uniquement comme une entreprise, mais n’en est pas une. Et enfin, s'il y a une demande pour quelque chose, alors il y aura toujours une offre (dans notre cas, il s'agit du « support » mentionné). Il y a une demande pour absolument tout, y compris. et des logiciels inutilisables. Comment cette demande se forme et qui l’alimente est un autre sujet.
Je ne tirerais donc aucune conclusion hâtive après la rumeur selon laquelle Facebook aurait déployé Btrfs sur ses serveurs. De plus, je recommanderais de garder soigneusement secrètes les adresses de ces serveurs pour les raisons ci-dessus.
Pourquoi tant d’efforts ont-ils été déployés pour nettoyer le code XFS ces derniers temps ? Après tout, il s'agit initialement d'un système de fichiers tiers, et ext4 est stable depuis longtemps et présente une continuité par rapport aux versions précédentes tout aussi stables. Quel intérêt Red Hat porte-t-il à XFS ? Est-il judicieux de développer activement deux systèmes de fichiers ayant un objectif similaire : ext4 et XFS ?
Je ne me souviens pas de ce qui a motivé cela. Il est fort possible que l'initiative soit venue des clients de Red Hat. Je me souviens que des recherches de ce genre avaient été menées : sur certains systèmes de fichiers venus de l'amont, un nombre gigantesque d'objets étaient créés sur des disques haut de gamme de nouvelle génération. D'après les résultats, XFS s'est mieux comporté que ext4. Ils ont donc commencé à le promouvoir comme étant le plus prometteur. En tout cas, je ne chercherais rien de sensationnel ici.
Pour moi, c’est comme s’ils avaient remplacé un poinçon par du savon. Cela ne sert à rien de développer ext4 et XFS. Les deux en parallèle et parmi lesquels choisir. Rien de bon n’en sortira. Cependant, dans la nature, il existe souvent des situations où il existe un grand potentiel de croissance, mais il n'y a pas de place pour se développer. Dans ce cas, diverses nouvelles excroissances bizarrement laides surgissent, que tout le monde pointe du doigt (« Oh, regarde, qu'est-ce que tu ne verras pas dans cette vie ! »).
Pensez-vous que le problème de la violation des couches a été réglé (dans un sens négatif) avec l'avènement des fonctions de chiffrement dans ext4, F2FS (sans parler du RAID dans Btrfs) ?
En général, l'introduction de n'importe quel niveau et la prise de décision quant à leur non-violation sont généralement une question de politique, et je ne m'engage à rien commenter ici. Les aspects objectifs de la violation de couche n'intéressent personne, mais nous pouvons en considérer certains en utilisant l'exemple de la violation « d'en haut », à savoir l'implémentation dans le FS d'une fonctionnalité qui existe déjà sur la couche de bloc. Une telle « violation » n’est justifiée qu’à de rares exceptions près. Pour chacun de ces cas, vous devez d’abord prouver deux choses : que cela est réellement nécessaire et que cela ne nuira pas à la conception du système.
Par exemple, la mise en miroir, qui est traditionnellement une activité de la couche bloc, est logique à mettre en œuvre au niveau du système de fichiers. Pour des raisons différentes. Par exemple, une corruption « silencieuse » des données (bit rot) se produit sur les lecteurs de disque. C'est à ce moment-là que l'appareil fonctionne correctement, mais que les données du bloc sont endommagées de manière inattendue sous l'influence d'un quantum gamma dur émis par un quasar distant, etc. Le pire est que ce bloc s'avère être un bloc système FS (superbloc, bloc bitmap, nœud d'arborescence de stockage, etc.), car cela entraînera certainement une panique du noyau.
Veuillez noter que les miroirs proposés par la couche bloc (appelée RAID 1) ne vous épargneront pas ce problème. Eh bien, vraiment : quelqu'un devrait vérifier les sommes de contrôle et lire la réplique en cas d'échec ? De plus, il est logique de refléter non seulement tout, mais uniquement les métadonnées. Certaines données importantes (par exemple, les fichiers exécutables d'applications critiques) peuvent être stockées sous forme de métadonnées. Dans ce cas, ils bénéficient des mêmes garanties de sécurité. Il est logique de confier la protection des données restantes à d'autres sous-systèmes (peut-être même aux applications utilisateur) - nous avons fourni toutes les conditions nécessaires pour cela.
De tels miroirs « économiques » ont le droit d’exister et ils ne peuvent être organisés efficacement qu’au niveau du système de fichiers. Sinon, la violation de la superposition encombre le sous-système de code en double au profit de certains avantages microscopiques. Un exemple frappant en est la mise en œuvre de RAID-5 utilisant FS. De telles solutions (propre RAID/LVM dans le système de fichiers) tuent ce dernier en termes architecturaux. Il convient également de noter ici que la violation de la superposition est « mise en avant » par divers types d’escrocs marketing. En l'absence d'idées, des fonctionnalités déjà implémentées depuis longtemps aux niveaux voisins sont ajoutées aux sous-systèmes, ceci est présenté comme une nouvelle fonctionnalité extrêmement utile et est activement poussé.
Reiser4 a été accusé d’avoir violé les niveaux « par le bas ». Partant du fait que le système de fichiers n'est pas monolithique, comme tous les autres, mais modulaire, une hypothèse non fondée a été émise selon laquelle il fait ce que le niveau supérieur (VFS) devrait faire.
Est-il possible de parler de la mort de ReiserFS v3.6 et, par exemple, de JFS ? Ces derniers temps, ils n’ont reçu pratiquement aucune attention. Sont-ils obsolètes ?
Ici, nous devons définir ce que signifie la mort d’un produit logiciel. D’une part, ils sont utilisés avec succès (c’est pour cela qu’ils ont été créés, après tout), ce qui signifie qu’ils vivent. Par contre, je ne peux pas parler pour JFS (je ne connais pas grand chose), mais ReiserFS (v3) est très difficile à adapter aux nouvelles tendances (testé en pratique). Cela signifie qu'à l'avenir, les développeurs n'y prêteront pas attention, mais à ceux qui sont plus faciles à adapter. De ce côté-ci, il s’avère que, hélas, il est mort du point de vue architectural. Je ne manipulerais pas du tout le concept de « moralement obsolète ». Cela s'applique bien, par exemple, à une garde-robe, mais pas aux produits logiciels. Il y a un concept d’infériorité et de supériorité dans quelque chose. Je peux absolument dire que ReserFS v3 est désormais inférieur à Reiser4 en tout, mais dans certains types de charge de travail, il est supérieur à tous les autres FS en amont.
Connaissez-vous le développement de FS Tux3 et HAMMER/HAMMER2 (FS pour DragonFly BSD) ?
Oui, nous savons. Dans Tux3, j'étais autrefois intéressé par la technologie de leurs instantanés (les soi-disant « pointeurs de version »), mais dans Reiser4, nous emprunterons très probablement une voie différente. Je réfléchis depuis longtemps à la prise en charge des instantanés et je n'ai pas encore décidé comment les implémenter pour de simples volumes Reiser4. Le fait est que la nouvelle technique de compteur de références « paresseux » proposée par Ohad Rodeh ne fonctionne que pour les arbres B. Nous ne les avons pas. Pour les structures de données utilisées dans Reiesr4, les compteurs « paresseux » ne sont pas définis - pour les introduire, il est nécessaire de résoudre certains problèmes algorithmiques que personne n'a encore résolus.
D'après HAMMER : J'ai lu un article du créateur. Pas intéressé. Encore une fois, les arbres B. Cette structure de données est désespérément obsolète. Nous l'avons abandonné au siècle dernier.
Comment évaluez-vous la demande croissante de FS en cluster réseau comme CephFS/GlusterFS/etc ? Cette demande signifie-t-elle un déplacement des priorités des développeurs vers le FS réseau et une attention insuffisante au FS local ?
Oui, un tel changement de priorités s’est produit. Le développement des systèmes de fichiers locaux a stagné. Hélas, faire quelque chose d'important pour les volumes locaux est désormais assez difficile et tout le monde ne peut pas le faire. Personne ne veut investir dans leur développement. Cela revient à peu près à demander à une organisation commerciale d'allouer de l'argent à la recherche mathématique - sans aucun enthousiasme, elle vous demandera comment gagner de l'argent avec un nouveau théorème. Désormais, un FS local est quelque chose qui apparaît comme par magie « prêt à l'emploi » et « devrait toujours fonctionner », et s'il ne fonctionne pas, il provoque des grognements non résolus du type : « Oui, à quoi pensent-ils ! »
D'où le manque d'attention accordée aux FS locaux, même s'il reste encore beaucoup de travail à faire dans ce domaine. Et oui, tout le monde s’est tourné vers le stockage distribué, construit sur la base de systèmes de fichiers locaux déjà existants. C'est très à la mode maintenant. L'expression « Big Data » provoque une montée d'adrénaline pour beaucoup, l'associant à des conférences, des ateliers, des salaires élevés, etc.
Dans quelle mesure est-il raisonnable en principe d'implémenter le système de fichiers réseau dans l'espace noyau plutôt que dans l'espace utilisateur ?
Une approche très raisonnable qui n’a encore été mise en œuvre nulle part. En général, la question de savoir dans quel espace un système de fichiers réseau doit être implémenté est une « arme à double tranchant ». Eh bien, regardons un exemple. Le client a enregistré des données sur une machine distante. Ils sont tombés dans son cache de pages sous forme de pages sales. C'est le travail d'un système de fichiers réseau à « passerelle légère » dans l'espace du noyau. Ensuite, le système d'exploitation vous demandera tôt ou tard d'écrire ces pages sur le disque pour les libérer. Ensuite, le module FS du réseau de transfert IO (envoi) entre en jeu. Il détermine à quelle machine serveur (nœud de serveur) ces pages iront.
Ensuite, la pile réseau prend le relais (et, comme nous le savons, elle est implémentée dans l'espace du noyau). Ensuite, le nœud du serveur reçoit ce paquet contenant des données ou des métadonnées et demande au module de stockage principal (c'est-à-dire le FS local qui fonctionne dans l'espace du noyau) d'enregistrer tout cela. Nous avons donc réduit la question à savoir où devraient fonctionner les modules « envoi » et « réception ». Si l'un de ces modules s'exécute dans l'espace utilisateur, cela entraînera inévitablement un changement de contexte (en raison de la nécessité d'utiliser les services du noyau). Le nombre de ces commutateurs dépend des détails de mise en œuvre.
S'il existe de nombreux commutateurs de ce type, le débit de stockage (performances d'E/S) diminuera. Si votre stockage backend est constitué de disques lents, vous ne remarquerez pas de baisse significative. Mais si vous disposez de disques rapides (SSD, NVRAM, etc.), le changement de contexte devient déjà un « goulot d'étranglement » et, en économisant sur le changement de contexte, les performances peuvent être considérablement augmentées. La manière standard d'économiser de l'argent consiste à déplacer les modules dans l'espace du noyau. Par exemple, nous avons constaté que le déplacement du serveur 9p de QEMU vers le noyau sur la machine hôte entraîne une multiplication par trois des performances de VirtFS.
Bien entendu, il ne s’agit pas d’un FS en réseau, mais il reflète pleinement l’essence des choses. L'inconvénient de cette optimisation réside dans les problèmes de portabilité. Pour certains, cette dernière peut être critique. Par exemple, GlusterFS n'a aucun module dans le noyau. Grâce à cela, il fonctionne désormais sur de nombreuses plateformes, dont NetBSD.
Quels concepts les FS locaux pourraient-ils emprunter à ceux du réseau et vice versa ?
De nos jours, les FS réseau ont généralement des modules complémentaires par rapport aux FS locaux, donc je ne comprends pas très bien comment vous pouvez emprunter quelque chose à ces derniers. Eh bien, en effet, considérons une entreprise de 4 salariés, dans laquelle chacun fait ce qu'il veut : l'un distribue, l'autre envoie, le troisième reçoit, le quatrième stocke. Et la question de savoir ce que l'entreprise peut emprunter à son employé qui le stocke semble en quelque sorte incorrecte (elle a déjà ce qu'elle aurait pu lui emprunter depuis longtemps).
Mais les FS locaux ont beaucoup à apprendre de ceux du réseau. Tout d’abord, vous devez apprendre d’eux comment agréger des volumes logiques à un niveau élevé. Maintenant, ce qu'on appelle Les systèmes de fichiers locaux « avancés » regroupent des volumes logiques exclusivement en utilisant la technologie de « périphérique virtuel » empruntée à LVM (cette même violation de superposition infectieuse qui a été implémentée pour la première fois dans ZFS). En d'autres termes, la traduction des adresses virtuelles (numéros de bloc) en adresses réelles et inversement se produit à un niveau bas (c'est-à-dire après que le système de fichiers a émis une requête d'E/S).
Veuillez noter que l'ajout et la suppression de périphériques sur des volumes logiques (et non des miroirs) disposés sur la couche de blocs entraînent des problèmes sur lesquels les fournisseurs de telles « fonctionnalités » restent modestement silencieux. Je parle de fragmentation sur des appareils réels, qui peuvent atteindre des valeurs monstrueuses, alors que sur un appareil virtuel tout va bien. Cependant, peu de gens s’intéressent aux appareils virtuels : tout le monde s’intéresse à ce qui se passe sur vos appareils réels. Mais les FS de type ZFS (ainsi que tout FS en conjonction avec LVM) ne fonctionnent qu'avec des périphériques de disque virtuel (attribuez des adresses de disque virtuel parmi celles libres, défragmentez ces périphériques virtuels, etc.). Et ils n’ont aucune idée de ce qui se passe sur les vrais appareils !
Imaginez maintenant que vous n'ayez aucune fragmentation sur le périphérique virtuel (c'est-à-dire que vous n'avez qu'une seule extension géante qui y réside), vous ajoutez un disque à votre volume logique, puis supprimez un autre disque aléatoire de votre volume logique, puis rééquilibrez. Et tant de fois. Il n’est pas difficile d’imaginer que sur un appareil virtuel, vous aurez toujours la même étendue de vie, mais sur des appareils réels, vous ne verrez rien de bon.
Le pire, c’est que vous n’arrivez même pas à corriger cette situation ! La seule chose que vous pouvez faire ici est de demander au système de fichiers de défragmenter le périphérique virtuel. Mais elle vous dira que tout y est génial : il n'y a qu'une seule étendue, la fragmentation est nulle, et ça ne peut pas être mieux ! Ainsi, les volumes logiques disposés au niveau des blocs ne sont pas destinés à l’ajout/suppression répétée de périphériques. Dans le bon sens, il vous suffit d'assembler une seule fois un volume logique au niveau du bloc, de le transmettre au système de fichiers, puis de ne rien faire d'autre avec.
De plus, la combinaison de sous-systèmes FS+LVM indépendants ne permet pas de prendre en compte la nature différente des disques à partir desquels les volumes logiques sont agrégés. En effet, supposons que vous ayez assemblé un volume logique à partir de disques durs et de périphériques SSD. Mais alors le premier nécessitera une défragmentation, et le second non. Pour ces derniers, vous devez émettre des demandes de rejet, mais pour les premiers non, etc. Cependant, dans cette combinaison, il est assez difficile de démontrer une telle sélectivité.
Notez qu'après avoir créé votre propre LVM sur le système de fichiers, la situation ne s'améliore guère. De plus, en procédant ainsi, vous mettez fin à toute perspective d’amélioration continue à l’avenir. C'est très mauvais. Différents types de lecteurs peuvent vivre sur la même machine. Et si le système de fichiers ne fait pas la distinction entre eux, alors qui le fera ?
Un autre problème attend ce qu'on appelle. Systèmes de fichiers « Write-Anywhere » (cela inclut également Reiser4, si vous avez spécifié le modèle transactionnel approprié lors du montage). De tels systèmes de fichiers doivent fournir des outils de défragmentation d’une puissance sans précédent. Et le gestionnaire de volume de bas niveau n'aide pas ici, mais ne fait que gêner. Le fait est qu'avec un tel gestionnaire, votre FS stockera une carte des blocs libres d'un seul appareil - un appareil virtuel. Par conséquent, vous ne pouvez défragmenter qu'un périphérique virtuel. Cela signifie que votre défragmenteur fonctionnera pendant très, très longtemps sur un immense espace unique d'adresses virtuelles.
Et si de nombreux utilisateurs effectuent des écrasements aléatoires, l'effet utile d'un tel défragmenteur sera réduit à zéro. Votre système commencera inévitablement à ralentir, et vous n'aurez qu'à croiser les mains devant le diagnostic décevant « conception cassée ». Plusieurs défragmenteurs exécutés sur le même espace d'adressage ne feront qu'interférer les uns avec les autres. C'est une tout autre affaire si vous conservez votre propre carte de blocs gratuits pour chaque appareil réel. Cela permettra de paralléliser efficacement le processus de défragmentation.
Mais cela ne peut être fait que si vous disposez d’un gestionnaire de volumes logiques de haut niveau. Les systèmes de fichiers locaux avec de tels gestionnaires n'existaient pas auparavant (du moins, je ne les connais pas). Seuls les systèmes de fichiers réseau (par exemple GlusterFS) disposaient de tels gestionnaires. Un autre exemple très important est l’utilitaire de vérification de l’intégrité des volumes (fsck). Si vous stockez votre propre carte indépendante de blocs libres pour chaque sous-volume, la procédure de vérification d'un volume logique peut être efficacement parallélisée. En d’autres termes, les volumes logiques gérés par des gestionnaires de haut niveau évoluent mieux.
De plus, avec les gestionnaires de volumes de bas niveau, vous ne pourrez pas organiser d'instantanés à part entière. Avec les systèmes de fichiers de type LVM et ZFS, vous ne pouvez prendre que des instantanés locaux, mais pas des instantanés globaux. Les instantanés locaux vous permettent d'annuler instantanément uniquement les opérations normales sur les fichiers. Et personne n'annulera les opérations avec des volumes logiques (ajout/suppression de périphériques). Regardons cela avec un exemple. À un moment donné, lorsque vous disposez d'un volume logique de deux périphériques A et B contenant 100 fichiers, vous prenez un instantané du système S, puis créez une centaine de fichiers supplémentaires.
Après cela, vous ajoutez le périphérique C à votre volume, puis restaurez votre système vers l'instantané S. Question : Combien de fichiers et de périphériques votre volume logique contient-il après la restauration vers S ? Il y aura 100 fichiers, comme vous l'avez peut-être deviné, mais il y aura 3 appareils - ce sont les mêmes appareils A, B et C, bien qu'au moment de la création de l'instantané, il n'y avait que deux appareils dans le système (A et B ). L'opération d'ajout de périphérique C n'a pas été annulée et si vous supprimez maintenant le périphérique C de l'ordinateur, cela corrompra vos données. Par conséquent, avant de supprimer, vous devrez d'abord effectuer une opération coûteuse pour supprimer le périphérique du volume logique de rééquilibrage, ce qui dispersera toutes les données du périphérique C vers les périphériques A et B. Mais si votre FS prenait en charge les instantanés globaux, un tel rééquilibrage ne serait pas nécessaire, et après un retour instantané vers S, vous pourriez supprimer en toute sécurité le périphérique C de l'ordinateur.
Ainsi, les instantanés globaux sont utiles car ils vous permettent d'éviter la suppression (l'ajout) coûteux d'un périphérique d'un volume logique (vers un volume logique) avec une grande quantité de données (bien sûr, si vous n'oubliez pas de « instantanéiser » votre système au bon moment). Permettez-moi de vous rappeler que la création d'instantanés et la restauration du système de fichiers sont des opérations instantanées. La question peut se poser : comment est-il même possible d'annuler instantanément une opération sur un volume logique qui vous a pris trois jours ? Mais c'est possible ! À condition que votre système de fichiers soit conçu correctement. J'ai eu l'idée de tels «instantanés 3D» il y a trois ans et l'année dernière j'ai breveté cette technique.
La prochaine chose que les FS locaux devraient apprendre de ceux du réseau est de stocker les métadonnées sur des appareils distincts de la même manière que les FS du réseau les stockent sur des machines distinctes (les soi-disant serveurs de métadonnées). Certaines applications fonctionnent principalement avec des métadonnées, et ces applications peuvent être considérablement accélérées en plaçant les métadonnées sur des périphériques de stockage coûteux et hautes performances. Avec la combinaison FS+LVM, vous ne pourrez pas démontrer une telle sélectivité : LVM ne sait pas ce qu'il y a sur le bloc que vous lui avez transmis (données ou métadonnées).
Vous n'obtiendrez pas beaucoup d'avantages en implémentant votre propre LVM de bas niveau dans le FS par rapport à la combinaison FS+LVM, mais ce que vous pouvez très bien faire, c'est encombrer le FS afin qu'il devienne plus tard impossible de travailler avec son code. ZFS et Btrfs, qui se sont précipités avec les périphériques virtuels, sont tous des exemples clairs de la façon dont la violation des couches tue le système en termes architecturaux. Alors, pourquoi suis-je tout cela ? De plus, il n'est pas nécessaire d'installer votre propre LVM de bas niveau dans le système de fichiers. Au lieu de cela, vous devez regrouper les périphériques en volumes logiques à un niveau élevé, comme le font certains systèmes de fichiers réseau avec différentes machines (nœuds de stockage). Certes, ils le font de manière dégoûtante en raison de l'utilisation de mauvais algorithmes.
Des exemples d'algorithmes absolument terribles sont le traducteur DHT dans le système de fichiers GlusterFS et la carte dite CRUSH dans le système de fichiers Ceph. Aucun des algorithmes que j'ai vus ne m'a satisfait en termes de simplicité et de bonne évolutivité. J'ai donc dû me souvenir de l'algèbre et tout inventer moi-même. En 2015, en expérimentant des bundles sur des fonctions de hachage, j'ai imaginé et breveté quelque chose qui me convient. Maintenant, je peux dire que la tentative de mettre tout cela en pratique a été couronnée de succès. Je ne vois aucun problème d’évolutivité dans la nouvelle approche.
Oui, chaque sous-volume nécessitera une structure distincte telle qu'un superbloc en mémoire. Est-ce très effrayant ? En général, je ne sais pas qui va « faire bouillir l’océan » et créer des volumes logiques de centaines de milliers d’appareils ou plus sur une machine locale. Si quelqu'un peut m'expliquer cela, je lui en serai très reconnaissant. En attendant, pour moi, ce sont des conneries marketing.
Comment les modifications apportées au sous-système de périphérique de bloc du noyau (par exemple, l'apparition de blk-mq) ont-elles affecté les exigences d'implémentation de FS ?
Ils n'ont eu aucun impact. Je ne sais pas ce qui se passerait sur la couche de blocs qui rendrait nécessaire la conception d'un nouveau FS. L'interface d'interaction de ces sous-systèmes est très médiocre. Du côté du pilote, le FS ne devrait être affecté que par l'apparition de nouveaux types de lecteurs, auxquels la couche de blocs sera ajustée en premier, puis le FS (pour reiser4, cela signifiera l'apparition de nouveaux plugins).
L'émergence de nouveaux types de supports (par exemple, SMR ou l'omniprésence des SSD) implique-t-elle des défis fondamentalement nouveaux pour la conception de systèmes de fichiers ?
Oui. Et ce sont des incitations normales pour le développement du FS. Les défis peuvent être différents et complètement inattendus. Par exemple, j'ai entendu parler de lecteurs sur lesquels la vitesse d'une opération d'E/S dépend fortement de la taille d'une donnée et de son décalage. Sous Linux, où la taille du bloc FS ne peut pas dépasser la taille de la page, un tel lecteur n'affichera pas toutes ses capacités par défaut. Cependant, si votre système de fichiers est conçu correctement, vous avez la possibilité d'en tirer beaucoup plus.
Combien de personnes travaillent actuellement avec le code Reiser4 à part vous ?
Moins que je ne le souhaiterais, mais je ne souffre pas non plus d’une grave pénurie de ressources. Je suis plus que satisfait du rythme de développement de Reiser4. Je ne vais pas « conduire des chevaux » - ce n'est pas le bon domaine. Ici, « si vous conduisez plus doucement, vous continuerez ! » Un système de fichiers moderne est le sous-système de noyau le plus complexe, dont les mauvaises décisions de conception peuvent annuler des années de travail humain ultérieur.
En proposant des volontaires pour mettre en œuvre quelque chose, je garantis toujours que les efforts conduiront certainement au résultat correct, qui peut être demandé pour des besoins sérieux. Comme vous le comprenez, il ne peut y avoir plusieurs garanties de ce type à la fois. En même temps, je ne supporte pas les « personnages » qui font la promotion sans vergogne de « fonctionnalités » de logiciels manifestement inutilisables, trompant des centaines d’utilisateurs et de développeurs, et qui en même temps s’assoient et sourient lors des sommets du noyau.
Une entreprise a-t-elle exprimé sa volonté de soutenir le développement de Reiser4 ?
Oui, il y a eu de telles propositions, incl. et d'un fournisseur majeur. Mais pour cela, j'ai dû déménager dans un autre pays. Malheureusement, je n’ai plus 30 ans, je ne peux pas m’échapper et repartir comme ça au premier coup de sifflet.
Quelles fonctionnalités manquent actuellement dans Reiser4 ?
Il n'y a pas de fonction de « redimensionnement » pour les volumes simples, similaire à celle trouvée dans ReiserFS(v3). De plus, les opérations sur les fichiers avec l'indicateur DIRECT_IO ne feraient pas de mal. Ensuite, j'aimerais pouvoir séparer un volume en « sous-volumes sémantiques », qui n'ont pas de taille fixe, et qui peuvent être montés comme des volumes indépendants. Ces problèmes conviennent aux débutants qui souhaitent s’essayer à la « vraie chose ».
Et enfin, j'aimerais disposer de volumes logiques réseau avec une mise en œuvre et une administration simples (les algorithmes modernes le permettent déjà). Mais ce que Reiser4 n'aura certainement jamais, ce sont RAID-Z, gommages, caches d'espace libre, variables 128 bits et autres absurdités marketing apparues dans un contexte de manque d'idées parmi les développeurs de certains systèmes de fichiers.
Tout ce qui pourrait être nécessaire peut-il être implémenté par des plugins ?
Si nous parlons uniquement en termes d'interfaces et de plugins (modules) qui les implémentent, alors pas tout. Mais si vous introduisez également des relations sur ces interfaces, vous aurez alors, entre autres choses, les concepts de polymorphismes supérieurs, avec lesquels vous pouvez déjà vous débrouiller. Imaginez que vous ayez hypothétiquement gelé un système d'exécution orienté objet, modifié la valeur du pointeur d'instruction pour pointer vers un autre plugin qui implémente la même interface X, puis dégelé le système afin qu'il continue à s'exécuter.
Si l'utilisateur final ne remarque pas une telle « substitution », alors nous disons que le système a un polymorphisme d'ordre zéro dans l'interface X (ou que le système est hétérogène dans l'interface X, ce qui est la même chose). Si maintenant vous disposez non seulement d'un ensemble d'interfaces, mais également de relations entre elles (graphe d'interface), alors vous pouvez introduire des polymorphismes d'ordres supérieurs, qui caractériseront l'hétérogénéité du système déjà dans le « voisinage » de n'importe quelle interface. J'ai introduit une telle classification il y a longtemps, mais malheureusement, cela n'a jamais eu lieu.
Ainsi, avec l'aide de plugins et de polymorphismes plus élevés, vous pouvez décrire n'importe quelle fonctionnalité connue, ainsi que « prédire » celles qui n'ont même jamais été mentionnées. Je n’ai pas pu le prouver strictement, mais je ne connais pas encore de contre-exemple. En général, cette question m’a rappelé le « Programme Erlangen » de Felix Klein. À une certaine époque, il essaya de représenter toute la géométrie comme une branche de l’algèbre (en particulier la théorie des groupes).
Passons maintenant à la question principale : comment se passent les choses avec la promotion de Reiser4 au sein du noyau principal ? Y a-t-il eu des publications sur l'architecture de ce système de fichiers dont vous avez parlé lors de la dernière interview ? Dans quelle mesure cette question est-elle pertinente de votre point de vue ?
En général, cela fait trois ans que nous demandons une intégration dans la branche principale. Le dernier commentaire de Reiser dans le fil de discussion public où la pull request a été faite est resté sans réponse. Toutes les autres questions ne sont donc pas pour nous. Personnellement, je ne comprends pas pourquoi nous devons « fusionner » dans un système d’exploitation spécifique. Sous Linux, la lumière ne convergeait pas comme un coin. Il existe donc un référentiel séparé dans lequel il y aura plusieurs ports de branche pour différents systèmes d'exploitation. Celui qui en a besoin peut cloner le port correspondant et en faire ce qu'il veut (dans le cadre de la licence, bien sûr). Eh bien, si quelqu’un n’en a pas besoin, ce n’est pas mon problème. À ce stade, je propose de considérer la question de la « promotion dans le noyau Linux principal » comme réglée.
Les publications sur l'architecture FS sont pertinentes, mais jusqu'à présent, je n'ai trouvé que du temps pour mes nouveaux résultats, que je considère comme une priorité plus élevée. Une autre chose est que je suis mathématicien, et en mathématiques toute publication est un résumé des théorèmes et de leurs preuves. Y publier quoi que ce soit sans preuve est un signe de mauvais goût. Si je prouve ou réfute complètement toute affirmation concernant l'architecture du FS, le résultat sera de tels tas qu'il sera assez difficile de les parcourir. Qui en a besoin ? C'est probablement la raison pour laquelle tout reste sous sa forme ancienne - le code source et ses commentaires.
Quoi de neuf chez Reiser4 ces dernières années ?
La stabilité tant attendue s’est enfin concrétisée. L'un des derniers à apparaître était un bug qui conduisait à des répertoires « non supprimables ». La difficulté était qu'il n'apparaissait que dans le contexte de collisions de hachage de noms et avec un certain emplacement des enregistrements de répertoire dans un nœud d'arborescence. Cependant, je ne peux toujours pas recommander Reiser4 pour la production : pour cela, vous devez effectuer un travail en interaction active avec les administrateurs du système de production.
Nous avons finalement réussi à mettre en œuvre notre idée de longue date : différents modèles de transaction. Auparavant, Reiser4 n'exécutait qu'un seul modèle Macdonald-Reiser codé en dur. Cela a créé des problèmes de conception. En particulier, les instantanés ne sont pas possibles dans un tel modèle transactionnel - ils seront corrompus par un composant atomique appelé « OVERWRITE SET ». Reiser4 prend actuellement en charge trois modèles de transaction. Dans l'un d'eux (Write-Anywhere), le composant atomique OVERWRITE SET ne comprend que des pages système (images de bitmaps de disque, etc.), qui ne peuvent pas être « photographiées » (le problème de la poule et de l'œuf).
Ainsi, les images peuvent désormais être réalisées de la meilleure façon possible. Dans un autre modèle transactionnel, toutes les pages modifiées vont uniquement dans le OVERWRITE SET (c'est-à-dire qu'il s'agit essentiellement d'une pure journalisation). Ce modèle s'adresse à ceux qui se plaignent de la fragmentation rapide des partitions Reiser4. Désormais, dans ce modèle, votre partition ne se fragmentera pas plus rapidement qu'avec ReiserFS (v3). Les trois modèles existants, avec quelques réserves, garantissent l'atomicité des opérations, mais des modèles avec perte d'atomicité et ne préservant que l'intégrité de la section peuvent également être utiles. De tels modèles peuvent être utiles pour toutes sortes d’applications (bases de données, etc.), qui assument déjà certaines de ces fonctions. Il est très simple d'ajouter ces modèles à Reiser4, mais je ne l'ai pas fait, car personne ne me l'a demandé et personnellement, je n'en ai pas besoin.
Des sommes de contrôle de métadonnées sont apparues et je les ai récemment complétées par des miroirs « économiques » (matériel encore instable). Si la somme de contrôle d'un bloc échoue, Reiser4 lit immédiatement le bloc correspondant à partir du périphérique de réplique. Notez que ZFS et Btrfs ne peuvent pas faire cela : la conception ne le permet pas. Là, vous devez exécuter un processus spécial d'analyse en arrière-plan appelé « scrub » et attendre qu'il atteigne le bloc problématique. Les programmeurs appellent de tels événements des « béquilles ».
Et enfin, des volumes logiques hétérogènes sont apparus, offrant tout ce que ZFS, Btrfs, couche de bloc, ainsi que les combinaisons FS+LVM ne peuvent en principe pas fournir - mise à l'échelle parallèle, alloueur d'adresses de disque O(1), migration transparente des données entre les sous-volumes. Ce dernier dispose également d’une interface utilisateur. Vous pouvez désormais facilement déplacer les données les plus importantes vers le disque le plus performant de votre volume.
De plus, il est possible de vider en urgence toutes les pages sales sur un tel lecteur, accélérant ainsi considérablement les applications qui appellent souvent fsync(2). Je note que la fonctionnalité de couche de bloc, appelée bcache, n'offre pas du tout une telle liberté d'action. Les nouveaux volumes logiques sont basés sur mes algorithmes (il existe des brevets correspondants). Le logiciel est déjà assez stable, il est tout à fait possible de l’essayer, de mesurer les performances, etc. Le seul inconvénient est que pour l'instant, vous devez mettre à jour manuellement la configuration du volume et la stocker quelque part.
Jusqu'à présent, j'ai pu mettre en œuvre mes idées à hauteur de 10 %, mais j'ai réussi ce que je considérais comme le plus difficile : connecter des volumes logiques avec une procédure flash qui effectue toutes les actions différées dans reiser4. Tout cela est encore dans la branche expérimentale « format41 ».
Reiser4 réussit-il les xfstests ?
Du moins, c'était le cas pour moi lorsque je préparais la dernière version.
Est-il possible en principe de faire de Reiser4 un réseau (cluster) FS à l'aide de plugins ?
C'est possible, et même nécessaire ! Si vous créez un fichier réseau basé sur un système de fichiers local correctement conçu, le résultat sera très impressionnant ! Dans les FS réseau modernes, je ne suis pas satisfait de la présence d'un niveau de stockage backend, qui est implémenté à l'aide de n'importe quel FS local. L'existence de ce niveau est totalement injustifiée. Le réseau FS doit interagir directement avec la couche bloc et ne pas demander au FS local de créer d'autres fichiers de service !
En général, diviser les systèmes de fichiers en local et en réseau est une mauvaise chose. Elle est née de l’imperfection des algorithmes utilisés il y a trente ans et pour lesquels rien n’a encore été proposé. C'est aussi la raison de l'apparition d'une masse de composants logiciels inutiles (services divers, etc.). Dans le bon sens, il ne devrait y avoir qu'un seul FS sous la forme d'un module de noyau et un ensemble d'utilitaires utilisateur installés sur chaque machine - un nœud de cluster. Ce FS est à la fois local et réseau. Et rien de plus!
Si rien ne fonctionne avec Reiser4 sous Linux, j'aimerais proposer un FS pour FreeBSD (citation d'une interview précédente : « …FreeBSD… a des racines académiques… Et cela signifie qu'avec un degré de probabilité élevé, nous trouvera un langage commun avec les développeurs ») ?
Ainsi, comme nous venons de le découvrir, tout a déjà parfaitement fonctionné avec Linux : il existe un port Reiser4 fonctionnel distinct pour celui-ci sous la forme d'une branche principale de notre référentiel. Je n'ai pas oublié FreeBSD ! Offre! Je suis prêt à travailler en étroite collaboration avec ceux qui connaissent bien les entrailles de FreeBSD. À propos : ce que j'aime vraiment dans leur communauté, c'est que les décisions y sont prises par un conseil actualisé d'experts indépendants, ce qui n'a rien à voir avec la tromperie du gouvernement sur une personne permanente.
Comment évaluez-vous la communauté des utilisateurs Linux aujourd’hui ? Est-ce devenu plus « pop » ?
Compte tenu de la nature de mon travail, il m'est assez difficile d'évaluer cela. La plupart du temps, les utilisateurs me viennent avec des rapports de bogues et des demandes de correction de la section. Les utilisateurs en tant qu'utilisateurs. Certains sont plus avisés, d’autres moins. Tout le monde est traité de la même manière. Eh bien, si l'utilisateur ignore mes instructions, alors excusez-moi : l'ordre d'ignorer sera également saisi de ma part.
Est-il possible de prédire l’évolution des systèmes de fichiers pour les cinq à dix prochaines années ? Selon vous, quels sont les principaux défis auxquels les développeurs FS peuvent être confrontés ?
Oui, faire une telle prévision n’est pas difficile. Il n'y a pas eu de développement de systèmes de fichiers en amont depuis longtemps. Seule l’apparence de celui-ci est créée. Les développeurs de systèmes de fichiers locaux ont rencontré des problèmes liés à une mauvaise conception. Une mise en garde doit être faite ici. Je ne considère pas le soi-disant « stockage », « léchage » et portage de code comme du développement et du développement. Et je ne qualifie pas le malentendu appelé « Btrfs » comme une évolution pour les raisons que j’ai déjà exposées.
Chaque patch ne fait qu'empirer les problèmes. Bien. et il existe toujours différentes sortes d’« évangélistes » pour qui « tout fonctionne ». Fondamentalement, ce sont des écoliers et des étudiants qui sautent les cours. Imaginez : cela fonctionne pour lui, mais pas le professeur. Quelle montée d'adrénaline c'est ! De mon point de vue, le plus grand mal est causé par les « artisans » qui se sont précipités pour « visser » avec enthousiasme les merveilleuses fonctionnalités de Btrfs sur toutes sortes de couches comme systemd, docker, etc. - cela ressemble déjà à des métastases.
Essayons maintenant de faire une prévision sur cinq à dix ans. J'ai déjà brièvement énuméré ce que nous ferons dans Reiser4. Le principal défi pour les développeurs FS locaux en amont sera (oui, c'est déjà devenu) l'incapacité de faire un travail décent pour un salaire. Sans aucune idée dans le domaine du stockage de données, ils continueront à essayer de patcher ces malheureux VFS, XFS et ext4. La situation de VFS semble particulièrement comique dans ce contexte, qui rappelle la modernisation effrénée d'un restaurant dans lequel il n'y a pas de chefs et aucun chef n'est attendu.
Désormais, le code VFS, sans aucune condition, verrouille plusieurs pages mémoire en même temps et invite le FS sous-jacent à les exploiter. Cela a été introduit pour améliorer les performances d'Ext4 lors des opérations de suppression, mais comme il est facile de le comprendre, un tel verrouillage simultané est totalement incompatible avec les modèles de transactions avancés. Autrement dit, vous ne pourrez pas simplement ajouter la prise en charge d'un système de fichiers intelligent dans le noyau. Je ne sais pas quelle est la situation dans d'autres domaines de Linux, mais en ce qui concerne les systèmes de fichiers, il est peu probable que tout développement ici soit compatible avec la politique menée par Torvalds dans la pratique (les projets universitaires sont expulsés et les escrocs qui je n'ai aucune idée de ce qu'est un arbre B, des crédits de confiance sans fin sont émis). Par conséquent, le cap a été mis sur une lente décadence. Bien sûr, ils essaieront de toutes leurs forces de faire passer cela pour du « développement ».
De plus, les « gardiens » des systèmes de fichiers, se rendant compte que vous ne gagnerez pas grand-chose uniquement avec le « stockage », s'essayeront à une activité plus rentable. Il s'agit généralement de systèmes de fichiers distribués et de virtualisation. Peut-être qu’ils porteront le ZFS à la mode ailleurs, là où il n’existe pas encore. Mais comme tous les FS d'amont, il ressemble à un arbre du Nouvel An : si vous pouvez accrocher d'autres petites choses dessus, vous ne pouvez pas aller plus loin. J'admets qu'il est possible de construire un système d'entreprise sérieux basé sur ZFS, mais puisque nous discutons maintenant de l'avenir, je ne peux que malheureusement déclarer que ZFS à cet égard est désespéré : avec leurs appareils virtuels, les gars ont coupé l'oxygène pour eux-mêmes et pour les générations futures en vue d'un développement ultérieur. ZFS appartient au passé. Et ext4 et XFS ne sont même pas avant-hier.
Il convient de mentionner séparément le concept sensationnel de « système de fichiers Linux de nouvelle génération ». Il s'agit d'un projet entièrement politique et marketing créé pour avoir l'opportunité, pour ainsi dire, de « fixer l'avenir des systèmes de fichiers » sous Linux derrière des personnages spécifiques. Le fait est que Linux était autrefois « juste pour le plaisir ». Mais aujourd’hui, c’est avant tout une machine à gagner de l’argent. Ils sont faits sur tout ce qui est possible. Par exemple, il est très difficile de créer un bon produit logiciel, mais les « développeurs » intelligents ont compris depuis longtemps qu'il n'y a aucune raison de se forcer : vous pouvez vendre avec succès un logiciel inexistant qui a été annoncé et promu auprès de toutes sortes de publics. événements - l'essentiel est que les diapositives de présentation contiennent plus de « fonctionnalités ».
Les systèmes de fichiers sont parfaits pour cela, car vous pouvez négocier le résultat en toute sécurité pendant dix ans. Eh bien, si quelqu'un se plaint plus tard de l'absence de ce résultat, c'est qu'il ne comprend tout simplement rien aux systèmes de fichiers ! Cela n’est pas sans rappeler une pyramide financière : au sommet se trouvent les aventuriers qui ont déclenché ce désordre, et les rares qui ont eu de la « chance » : ils ont « retiré les dividendes », c’est-à-dire reçu de l'argent pour le développement, obtenu un emploi bien rémunéré en tant que manager, « s'est présenté » à des conférences, etc.
Viennent ensuite ceux qui sont « malchanceux » : ils vont compter les pertes, faire face aux conséquences du déploiement en production d'un produit logiciel inutilisable, « etc. Il y en a beaucoup plus. Eh bien, à la base de la pyramide, il y a une énorme masse de développeurs « sciant » du code inutile. Ce sont eux les plus grands perdants, car le temps perdu ne peut être récupéré. De telles pyramides sont extrêmement bénéfiques pour Torvalds et ses associés. Et plus il y a de pyramides, mieux c'est pour elles. Pour nourrir de telles pyramides, tout peut être introduit dans le noyau. Bien sûr, en public, ils disent le contraire. Mais je ne juge pas par des mots mais par des actes.
Ainsi, « l’avenir des systèmes de fichiers sous Linux » est encore un autre logiciel très promu, mais difficilement utilisable. Après Btrfs, avec une forte probabilité, la place d'un tel "futur" sera prise par Bcachefs, qui est une autre tentative de traverser la couche de blocs Linux avec un système de fichiers (un mauvais exemple est contagieux). Et ce qui est typique : il y a les mêmes problèmes que dans Btrfs. Je m'en doutais depuis longtemps, puis, d'une manière ou d'une autre, je n'ai pas pu résister et j'ai examiné le code - c'est vrai !
Les auteurs de Bcachefs et Btrfs, lors de la création de leur FS, ont activement utilisé les sources d'autres personnes, les comprenant peu. La situation rappelle beaucoup le jeu d'enfants « Téléphone cassé ». Et je peux à peu près imaginer comment ce code sera inclus dans le noyau. En fait, personne ne verra les « râteaux » (tout le monde marchera dessus plus tard). Après de nombreuses arguties sur le style du code, des accusations de violations inexistantes, etc., une conclusion sera tirée sur la « loyauté » de l'auteur, sur la manière dont il « interagit » avec les autres développeurs et sur le succès de tout cela. puis être vendu à des sociétés.
Le résultat final n’intéressera personne. Il y a vingt ans, j'aurais peut-être été intéressé, mais maintenant les questions se posent différemment : sera-t-il possible de promouvoir cela pour que certaines personnes soient employées dans les dix prochaines années. Et, hélas, il n’est pas d’usage de s’interroger sur le résultat final.
En général, je vous déconseille fortement de commencer à réinventer votre système de fichiers à partir de zéro. Car même des investissements financiers importants ne suffiront pas à obtenir quelque chose de compétitif dans dix ans. Bien sûr, je parle de projets sérieux, et non de ceux qui sont destinés à être « poussés » dans le noyau. Ainsi, une manière plus efficace de s’exprimer est de rejoindre des développements réels, comme nous. Bien sûr, ce n’est pas facile à faire – mais c’est le cas de tout projet de haut niveau.
Tout d'abord, vous devrez surmonter de manière indépendante le problème que je vais vous proposer. Après quoi, convaincu du sérieux de vos intentions, je commencerai à vous aider. Traditionnellement, nous utilisons uniquement nos propres développements. Les exceptions sont les algorithmes de compression et certaines fonctions de hachage. Nous n’envoyons pas de développeurs se rendre à des conférences, puis nous ne nous asseyons pas et ne combinons pas les idées des autres (« peut-être ce qui va arriver »), comme c’est l’habitude dans la plupart des startups.
Nous développons nous-mêmes tous les algorithmes. Je m'intéresse actuellement aux aspects algébriques et combinatoires de la science du stockage de données. En particulier, champs finis, asymptotiques, preuve d'inégalités. Il y a aussi du travail pour les programmeurs ordinaires, mais je dois vous prévenir tout de suite : toutes les suggestions de « regarder un autre FS et faire de même » sont ignorées. Des correctifs visant une intégration plus étroite avec Linux via VFS y seront également envoyés.
Nous n’avons donc pas de commission, mais nous comprenons où nous devons aller et nous sommes convaincus que cette direction est la bonne. Cette compréhension n’est pas venue du ciel sous forme de manne. Permettez-moi de vous rappeler que nous avons derrière nous 29 ans d'expérience en développement, deux systèmes de fichiers écrits à partir de zéro. Et le même nombre d'utilitaires de récupération de données. Et c'est beaucoup !
Source: opennet.ru