Überlegungen von Theodore Ts’o, dem Erfinder des Ext4-Dateisystems, zur Entwicklung von ext4, dem BcacheFS-Dateisystem, dem Linux-Kernel, ZFS, dem Verhaltenskodex und Dateisystemen im Allgemeinen:
Zur Entwicklung von ext4.
Für jede Version des ext4-Kernels arbeiten mehr als ein halbes Dutzend Personen daran. Derzeit verbringe ich den Großteil meiner Zeit mit der Überprüfung von Code, der Durchführung von Tests und der Verbesserung der Testanwendung {kvm,gce,qemu,android}-xfstests. Ich verlasse mich sehr auf 2-3 andere Entwickler von SUSE und IBM, die mir bei der Überprüfung des Codes helfen.
Über BcacheFS
Um ehrlich zu sein, bcachefs ist kein vollständig eigenständiges Projekt – zum Beispiel war Kent für 72 % der Patches zwischen den Kernel-Versionen 6.11 und 6.12 verantwortlich, während ich von 103 Patches für ext4 in diesem Zeitraum genau 0 % beigetragen habe. Das liegt daran, dass ich fest davon überzeugt bin, dass Programmieren eine Teamsportart ist, und meine Aufgabe als technischer Leiter darin besteht, den Mitgliedern des ext4-Teams zu ermöglichen, alles zu tun, um das Dateisystem zu verbessern. Wir halten wöchentliche Konferenzen ab, und Derrick Wong, leitender Entwickler von XFS und ehemaliger Betreuer von XFS, nimmt an diesen Konferenzen teil – und ich habe ihm bekanntlich bei Testfragen zu XFS geholfen, während Derrick mir bei verschiedenen Testfragen zu ext4 geholfen hat und sogar ein paar Patches zu ext4 geprüft hat. Wir arbeiten eng zusammen, und das ist gut.
Ich lasse anderen die Entscheidung, ob sie ihre Daten einem alleinstehenden, talentierten Programmierer anvertrauen wollen, der vielleicht begabter ist als ich. Doch ich gebe Ihnen einen Hinweis: Man kann "schummeln", indem man ein Team zur Lösung eines Problems einbezieht. Es ist nicht notwendig, alles alleine zu machen. Natürlich müssen Sie wissen, wie man das Beste in anderen weckt, und Sie sollten zusammenarbeiten. Höflichkeit in Mailinglisten schadet ebenfalls nicht.
Über den Kern, CoC, Möglichkeiten und die Zukunft von ext4
Ext4 erhält tatsächlich einige neue Funktionen, jedoch handelt es sich dabei um solche, die von den Unternehmen finanziert werden, da die Rentabilität der Funktionsentwicklung aus Kosten- und Nutzenperspektive sinnvoll ist. So waren beispielsweise fscrypt und die Groß-/Kleinschreibung ignorierenden Verzeichnisse Funktionen, die für Android und Chrome OS nützlich waren und zumindest teilweise von diesen Entwicklergruppen finanziert wurden (Steam war ebenfalls besorgt über die Groß-/Kleinschreibung und unterstützte einen der Ingenieure). Wir möchten Unterstützung für ununterbrochene Schreibvorgänge (untorn) hinzufügen, da dies die Leistung von Datenbanken auf cloud-gestützten emulierten Blockgerätssystemen verbessern wird, wo 16k atomare Schreibvorgänge garantiert werden können. Dies würde die doppelte Pufferung in MySQL und PostgreSQL überflüssig machen.
(Tatsächlich können Amazon und Google dies in ihren eigenen DB-Produkten tun, indem sie Annahmen darüber treffen, wie Amazon EBS und Google Persistent Disk funktionieren. Wir möchten jedoch einen allgemeineren Ansatz wählen, der langfristig besser wartbar ist. Das ist weniger verlockend als Dinge wie Reflinks, aber die Rentabilität ist viel leichter zu begründen, sowohl aufgrund niedrigerer Kosten (weniger Aufwand für Entwicklung, Tests und Qualifizierung für das Unternehmensdeployment) als auch weil die Vorteile viel einfacher messbar sind. So etwas wie „Ich kann die Gehälter von XX Vollzeit-Software-Ingenieuren über fünf Jahre einsparen“ ist für solche Leistungssteigerungsfunktionen viel leichter darzustellen.
Im Gegensatz dazu sind Reflinks zwar unterhaltsam, aber ich konnte keinen Kunden finden, der bereit ist, die Entwicklungskosten zu tragen, noch ein Unternehmen, das glaubt, dass seine Kunden mehr von ihrem Produkt kaufen würden, wenn sie Reflinks in ext4 einfügen. Das mag äußerst geschäftsmäßig erscheinen, doch gibt es die Geschichte, wie die Ingenieure von ZFS ein Projekt von Grund auf neu starteten, ohne die Genehmigung des Managements einzuholen oder Vorschläge von der Vertriebsabteilung zu erhalten, und Sun tatsächlich etwas präsentierten, das bereits vollbracht war.
Das klingt gut, aber wenn man bedenkt, dass Sun schließlich Geld verlor und gezwungen war, sich an ein anderes Unternehmen zu verkaufen, und dass die Ingenieursorganisation, die ZFS unterstützte, faktisch nicht mehr existiert. Ungefähr zur Zeit der Ankündigung von ZFS war ich an einer gesamten Unternehmensstudie beteiligt, um zu beurteilen, ob es sinnvoll sei, in Dateisystemfunktionen für AIX und Linux zu investieren – und wir kamen zu dem Schluss, dass dies nicht der Fall sei, der ROI gering sei und neue Dateisystemfunktionen nicht zu einer Zunahme der Kunden führen würden, die Hardware, Software oder IBM-Systeme kaufen. Möglicherweise hatte IBM schwere Zeiten, aber sie existiert immer noch, während Sun es nicht tut.
Ungefähr zu dieser Zeit kamen Vertreter mehrerer Linux-Unternehmen zusammen, um darüber nachzudenken, wie Linux mit ZFS konkurrieren könnte. Auf diesem Treffen wurde die Idee geäußert, dass btrfs die langfristige Lösung sein wird, während ext4 eine kurzfristige Lösung darstellt, die Unterstützung für Dinge wie die Anpassung von Größen in Echtzeit, 64-Bit-Blocknummern und andere Funktionen bieten wird, die in traditionellen Legacy-Unix-OS vorhanden waren und in ext3 nicht verfügbar waren.
Bei diesem Treffen wurde ich gebeten, die Anforderungen zur Erstellung eines völlig neuen Dateisystems zu definieren. Ich habe recherchiert, um herauszufinden, wie viel Aufwand bei der Entwicklung solcher Dateisysteme wie GPFS und JFS von IBM sowie advfs von Digital nötig war. Außerdem habe ich bewertet, wie lange Sun für die Entwicklung von ZFS benötigt hat, bis dieses Dateisystem betriebsbereit war. Die Antwort, die ich erhielt, belief sich auf etwa 100 Personenjahre, mit einer niedrigen Schätzung von 50 Personenjahren und einer hohen Schätzung von 200 Personenjahren (dies galt jedoch für GPFS, das ein clustered Filesystem ist und daher wesentlich komplexer ist).
Ich berichtete darüber in der Besprechung, und ein leitender Ingenieur von Intel sagte: 'Sagen Sie das nicht den Entscheidungsträgern, denn sie werden das Projekt niemals genehmigen! Sagen Sie ihnen, dass btrfs in 18 Monaten einsatzbereit sein wird.' Ich lasse es den Leuten überlassen zu entscheiden, wann btrfs den Status 'bereit für den Unternehmenseinsatz' erreichen wird, insbesondere für die neuen, attraktiven erweiterten Funktionen, die mit ZFS konkurrieren sollten. Aber ich denke nicht, dass es zur Diskussion steht, dass das nicht in 18 Monaten geschehen ist.
Und selbst bevor Sun zerfiel, hatten viele Unternehmen, die ihre Vertreter zu dem Treffen gesandt hatten, die Teilnahme von Ingenieuren an der Arbeit an btrfs abgelehnt, und das hat natürlich nicht geholfen. Wahrscheinlich lag das daran, dass Unternehmen rationale Organisationen sind, die ihre eigenen Entscheidungen zur Rentabilität von Investitionen treffen, und die Finanzierung eines neuen Dateisystems nicht so viel Sinn machte, wie den Leuten zu erzählen, dass Linux eine Antwort auf ZFS haben würde.
Rückblickend kann man sagen, dass ZFS zwar wirklich coole Funktionen hatte, es aber nicht ausreichte, um die meisten Benutzer dazu zu bringen, Solaris anstelle viel günstigerer x86-Plattformen zu wählen und Linux zu installieren. Und zu dem Zeitpunkt, als Sun beschloss, die OpenSolaris- und Solaris-x86-Strategie auszuprobieren, war es bereits zu spät. Die Netzwerkeffekte waren enorm, und die x86-Strategie bot keine Antwort auf die Frage, wie ein Unternehmen, Sun, all die hochqualifizierten Ingenieure, die an Solaris arbeiteten, bezahlen konnte. Der Kauf eines x86-Servers für 5000 Dollar bietet keine große Rentabilität im Vergleich zu dem Server durch SunFire E10k Sparc für 100000 Dollar, den Sun als den „Punkt“ im „Dot Com“ bezeichnete.
Der Punkt ist, dass Ingenieurarbeit in der realen Welt ein Kompromiss ist, und die geschäftlichen Realitäten sind Teil dieses Kompromisses. Ich entschuldige mich nicht dafür, dass ich lieber Essen genieße und dass ich genug Geld verdienen möchte, um eines Tages in Rente zu gehen. Das bedeutet wiederum, dass ich gut verstehen muss, wie ich meinem Arbeitgeber einen Nutzen bringe, der mindestens das Zehnfache meines Gehalts beträgt. Wenn ich das schaffen kann, während ich weiterhin mit Open Source arbeite und anderen Unternehmen helfe, Geld zu verdienen, damit sie bereit sind, in ext4 zu investieren, nun, das ist Teil der Herausforderung und der Grund, warum ich gerne mit Open Source arbeite.
Und um zum Verhaltenskodex zurückzukehren, möchte ich sagen, dass fast alle Maintainer der gängigen Dateisysteme diesen Kodex nicht aus irgendwelchen trüben liberalen Überlegungen unterstützt haben. Es liegt daran, dass wir jeden Ingenieur brauchen, der bereit ist, seinen Beitrag zu unserem Projekt zu leisten, und die meisten von uns haben Leute gesehen, die sich geweigert haben, an Linux zu arbeiten und zu anderen Betriebssystemen gewechselt sind (ich kenne jemanden, der auf Windows gewechselt ist und ein wertvoller Kernel-Entwickler im IBM Linux Technology Center war) oder an internen Projekten gearbeitet haben, aber nicht an solchen, die eine Interaktion mit dem LKML erforderten, wegen der toxischen Umgebung einiger weniger Personen in der Mailingliste.
In einigen Fällen waren die Bedenken unbegründet; zum Beispiel schrie Linus einen älteren Entwickler an, der es tatsächlich besser wissen sollte und mit dem Linus in den meisten Fällen persönlich in Kontakt stand, und sie hatten bereits eine etablierte Beziehung. Das Problem ist, dass Neulinge das nicht wussten und verängstigt waren – "Was ist, wenn Linus mich öffentlich erniedrigt, so wie er es mit Steve gemacht hat?", ohne zu verstehen, dass dies in der Praxis nicht passieren wird. Deshalb haben wir einen Verhaltenskodex; dieser ist nicht für uns, die älteren Ingenieure, sondern zur Unterstützung der jüngeren Ingenieure in unseren Teams, die wir ausbilden möchten, damit sie uns irgendwann ersetzen können, wenn die Zeit für unseren Rücktritt gekommen ist oder wir von einem Bus überfahren werden oder aus anderen Gründen diese vergängliche Welt verlassen.
Vergessen Sie nicht, dass 50-100 Person-Jahre in die Entwicklung eines dateisystemgerechten Lösung für den Unternehmenseinsatz geflossen sind. Wir benötigen alle Ingenieure, die wir gewinnen können, und viele von uns leisten auch in ihrer Freizeit zusätzliche Arbeit, weil uns das Thema am Herzen liegt. Die Erstellung eines hochwertigen Dateisystems ist Teamarbeit, und wir brauchen jeden talentierten Ingenieur, den wir bekommen können. Selbst wenn ein Ingenieur ein super 10x-Programmierer ist, ist es einfach nicht wert, jemanden zuzulassen, der andere Ingenieure, die an Tests, Leistungsoptimierungen usw. arbeiten könnten, abschreckt.
Quelle: opennet.ru
