Übersetzung der Überlegungen von Theodore Ts’o, dem Schöpfer des Dateisystems Ext4, zur Entwicklung von ext4, dem Dateisystem BcacheFS, dem Linux-Kernel, ZFS, dem Verhaltenskodex und Dateisystemen im Allgemeinen:
Zur Entwicklung von ext4.
An jeder Veröffentlichung des ext4-Kernels sind mehr als ein halbes Dutzend Personen beteiligt. Derzeit widme ich den Großteil meiner Zeit der Überprüfung von Code, dem Durchführen von Tests und der Verbesserung der Testanwendung {kvm,gce,qemu,android}-xfstests. Ich verlasse mich stark auf 2-3 andere Entwickler, die bei SUSE und IBM arbeiten und mir bei der Codeüberprüfung helfen.
Zu BcacheFS
Um ehrlich zu sein, ist bcachefs 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 in dem gleichen Zeitraum bei 103 Patches für ext4 genau 0 % beigetragen habe. Das liegt daran, dass ich fest davon überzeugt bin, dass Programmieren ein Teamsport ist, und meine Aufgabe als technischer Leiter darin besteht, den ext4-Mitgliedern zu ermöglichen, alles zu tun, um das Dateisystem zu verbessern. Wir führen wöchentliche Konferenzen durch, und Derrick Wong, leitender Entwickler von XFS und ehemaliger Betreuer von XFS, nimmt an diesen Konferenzen teil – und ich habe ihm bekanntlich bei Fragen zur XFS-Überprüfung geholfen, während Derrick mir bei verschiedenen Fragen zur ext4-Überprüfung und sogar bei der Betrachtung einiger ext4-Patches geholfen hat. Wir arbeiten zusammen, und das ist gut.
Ich lasse anderen Personen die Entscheidung, ob sie ihre Daten jemandem anvertrauen möchten, der ein einzelner talentierter Programmierer ist, der möglicherweise talentierter ist als ich, aber ich gebe Ihnen einen Hinweis – Sie können 'schummeln', indem Sie ein Team zur Problemlösung einbeziehen. Es ist nicht notwendig, dies alleine zu tun. Natürlich müssen Sie wissen, wie Sie das Beste in anderen wecken können, und Sie müssen zusammenarbeiten. Auch ein höflicher Umgang miteinander in Mailinglisten schadet nicht.
Zum Kernel, CoC, den Fähigkeiten und der Zukunft von ext4
Ext4 erhält tatsächlich einige neue Funktionen, aber es sind die, die die Unternehmen bereit sind zu finanzieren, da die Rentabilität der Entwicklung einer Funktion in Bezug auf Kosten und Vorteile sinnvoll ist. Beispielsweise waren fscrypt und case-insensitive Verzeichnisse Funktionen, die für Android und Chrome OS nützlich waren und die zumindest teilweise von diesen Entwicklergruppen finanziert wurden (Steam machte sich auch Sorgen um die Groß- und Kleinschreibung und unterstützte einen der Ingenieure). Wir möchten die Unterstützung für ununterbrochene (untorn) Schreibvorgänge hinzufügen, da dies die Leistung von Datenbanken auf Cloud-emulierten Blockgeräten verbessern wird, wo 16k atomare Schreibvorgänge garantiert werden können, was die doppelte Pufferung in MySQL und PostgreSQL überflüssig macht.
(Tatsächlich können Amazon und Google dies in ihren eigenen DB-Produkten tun, indem sie Annahmen über die Funktionsweise von Amazon EBS und Google Persistent Disk treffen, aber wir möchten dies auf eine allgemeinere Weise tun, die langfristig besser unterstützt werden kann). Es ist weniger attraktiv als Dinge wie Reflinks, aber die Rentabilität ist viel leichter zu rechtfertigen, sowohl weil die Kosten niedriger sind (weniger Aufwand für Entwicklung, Test und Qualifizierung für die Unternehmensbereitstellung), als auch weil die Vorteile viel leichter quantifiziert werden können. Solche Aussagen wie „Ich kann die Gehaltskosten von XX Festangestellten über fünf Jahre sparen“, sind für solche Leistungssteigerungsfunktionen viel einfacher zu machen.
Im Gegensatz dazu sind Reflinks zwar spannend, aber ich konnte keinen Kunden finden, der bereit war, die Entwicklungskosten zu tragen, oder ein Unternehmen, das denkt, dass ihre Kunden mehr von ihrem Produkt kaufen werden, wenn sie Reflinks in ext4 hinzufügen. Das mag schrecklich unternehmerisch erscheinen, aber es gibt eine Geschichte über Ingenieure von ZFS, die ein Projekt von Grund auf ohne Erlaubnis von der Geschäftsleitung und ohne Vorschläge von der Vertriebsabteilung begonnen haben und Sun etwas präsentierten, das tatsächlich ein vollendeter Fakt war.
Klingt gut, aber wenn man bedenkt, dass Sun schließlich anfing, Geld zu verlieren, bis sie gezwungen waren, sich an ein anderes Unternehmen zu verkaufen, und die Ingenieure, die ZFS unterstützen, tatsächlich nicht mehr existieren. Etwa zu der Zeit, als ZFS angekündigt wurde, war ich an einer Unternehmensforschung beteiligt, um herauszufinden, ob es sinnvoll wäre, in Dateisystemfunktionen für AIX und Linux zu investieren — und wir kamen zu dem Schluss, dass dies nicht der Fall war, die Rentabilität der Investitionen gering war und neue Dateisystemfunktionen nicht zu einer Erhöhung der Kunden führen würden, die Hardware, Software oder IBM-Systeme kaufen. Vielleicht erlebte IBM schwere Zeiten, aber sie existiert immer noch, während Sun nicht mehr existiert.
Etwa zur gleichen Zeit kamen Vertreter mehrerer Linux-Unternehmen zusammen, um zu überlegen, wie Linux mit ZFS konkurrieren könnte. Bei diesem Treffen wurde die Idee geäußert, dass btrfs die langfristige Antwort sein würde, während ext4 eine kurzfristige Lösung darstellt, die Unterstützung für Dinge wie dynamische Größenänderung, 64-Bit-Blocknummern und andere Features gewährleistet, die in traditionellen Legacy-Unix-OS enthalten waren und nicht in ext3.
Bei diesem Treffen bat man mich, zu definieren, was nötig wäre, um ein völlig neues Dateisystem zu entwickeln. Ich führte eine Recherche durch, indem ich mir ansah, wie viel Aufwand für die Erstellung von Dateisystemen wie GPFS und JFS von IBM sowie advfs von Digital erforderlich war, und schätzte, wie viel Zeit Sun für die Entwicklung von ZFS und die Vollausrüstung dieses Dateisystems benötigt hatte. Die Antwort, die ich erhielt, lag bei etwa 100 Mannjahren, wobei eine niedrige Schätzung bei 50 Mannjahren und eine hohe Schätzung bei 200 Mannjahren lag (aber das war für GPFS, das ein Clusterdatenbanksystem war und daher viel komplexer).
Ich berichtete darüber in der Sitzung, und ein leitender Ingenieur von Intel sagte: "Nein, sag das nicht den Führungskräften, denn sie werden das Projekt niemals genehmigen! Sag ihnen, dass btrfs in 18 Monaten bereit sein wird." Ich lasse die Leute selbst entscheiden, wann btrfs den Status „bereit für den Unternehmenseinsatz“ erreicht, insbesondere für die neuen attraktiven erweiterten Funktionen, die mit ZFS konkurrieren sollten, aber ich glaube nicht, dass es zur Diskussion steht, dass dies nicht in 18 Monaten geschehen ist.
Selbst bevor Sun sich auflöste, zogen viele Unternehmen, die ihre Vertreter zu dem Treffen entsandten, es vor, ihre Ingenieure nicht an der Arbeit mit btrfs teilnehmen zu lassen, was natürlich nicht hilfreich war. Aber wahrscheinlich hatte das damit zu tun, dass Unternehmen rationale Organisationen sind, die eigene Entscheidungen über die Rentabilität von Investitionen treffen, und die Finanzierung eines neuen Dateisystems keinen so hohen Stellenwert hatte wie die Aussage, dass Linux eine Antwort auf ZFS bieten würde.
Wenn man zurückblickt, kann man sagen, dass ZFS zwar diese wirklich coolen Funktionen hatte, diese jedoch nicht ausreichten, um die meisten Benutzer dazu zu bewegen, sich für Solaris zu entscheiden, anstatt viel billigere x86-Plattformen zu kaufen und Linux zu installieren. Und als Sun beschloss, die Strategie von OpenSolaris und Solaris x86 auszuprobieren, war es bereits zu spät. Die Netzwerkeffekte waren enorm, und die x86-Strategie beantwortete nicht die Frage, wie ein einziges Unternehmen, Sun, es zahlen konnte, alle hochqualifizierten Ingenieure, die an Solaris arbeiteten, zu beschäftigen. Der Kauf eines x86-Servers für 5000 Dollar bringt im Vergleich zu Server SunFire E10k Sparc für 100000 Dollar, den Sun als "Punkt" in der "Dot Com" bezeichnete, nicht viel Rentabilität.
Das Wesentliche ist, dass Ingenieurtätigkeit 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 es vorziehe, Essen zu essen, und dass ich genug Geld verdienen möchte, um eines Tages in Rente zu gehen. Und das bedeutet wiederum, dass ich gut verstehen muss, wie ich dem Arbeitgeber einen Nutzen bringe, der zumindest das Zehnfache meines Gehalts übersteigt. Wenn ich das kann, während ich weiterhin an Open-Source-Projekten arbeite und anderen Unternehmen helfe, Geld zu verdienen, damit sie bereit sind, in ext4 zu investieren, nun ja, das ist Teil der Herausforderung und der Grund, warum ich gerne mit Open Source arbeite.
Und wenn ich zum Verhaltenskodex zurückkomme, möchte ich sagen, dass fast alle Maintainer der Hauptdateisysteme den Kodex nicht aus irgendeinem schwachen liberalen Motiv unterstützt haben. Es liegt daran, dass wir jeden Ingenieur brauchen, der bereit ist, zu unserem Projekt beizutragen, und die meisten von uns haben Leute gesehen, die sich geweigert haben, in Linux zu arbeiten und auf andere Betriebssysteme gewechselt sind (ich kenne eine Person, die auf Windows gewechselt hat und ein wertvoller Linux-Kernel-Entwickler im IBM Linux Technology Center war) oder an internen Projekten gearbeitet haben, aber nicht an denen, die die Interaktion mit LKML erforderten, wegen der toxischen Umgebung einiger Personen auf der Mailingliste.
In einigen Fällen waren die Bedenken unbegründet; zum Beispiel schrie Linus einen Senior-Entwickler an, der es wirklich besser wissen sollte und mit dem Linus in den meisten Fällen persönlich zu tun hatte und mit dem er bereits eine Beziehung aufgebaut hatte. Das Problem ist, dass Neulinge dies nicht wussten und Angst hatten — „Was ist, wenn Linus mich öffentlich erniedrigt, so wie er es mit Steve gemacht hat?“, ohne zu verstehen, dass das in der Praxis nicht passieren wird. Deshalb haben wir den CoC; er ist nicht für uns, die älteren Ingenieure, sondern zur Unterstützung jüngerer Ingenieure in unseren Teams, die wir ausbilden möchten, damit sie uns irgendwann ersetzen können, wenn die Zeit zum Ruhestand gekommen ist, oder uns ein Bus überfährt, oder wir auf andere Weise diese vergängliche Welt verlassen.
Vergessen Sie nicht, dass es 50-100 Mannjahre Arbeit braucht, um ein Dateisystem zu entwickeln, das für den Einsatz in Unternehmensumgebungen bereit ist. Wir benötigen jeden Ingenieur, den wir gewinnen können, und viele von uns leisten zusätzliche Arbeit in ihrer Freizeit, weil uns nicht alles gleichgültig ist. Die Entwicklung eines hochwertigen Dateisystems ist Teamarbeit, und wir brauchen jeden talentierten Ingenieur, den wir bekommen können. Selbst wenn ein Ingenieur ein super 10-facher Programmierer ist, wenn er am Ende eine Menge anderer Ingenieure vertreibt, die an Tests, Leistungsoptimierung usw. arbeiten könnten, lohnt es sich einfach nicht, jemanden ein A...loch sein zu lassen.
Quelle: opennet.ru
