Das zweite Interview mit Eduard Shishkin, Entwickler des Reiser4-Dateisystems, wurde veröffentlicht.
Bitte erinnern Sie die Leser zunächst daran, wo und für wen Sie arbeiten.
Ich arbeite als Principal Storage Architect bei Huawei Technologies, Deutsches Forschungszentrum. In der Virtualisierungsabteilung beschäftige ich mich mit verschiedenen Aspekten der Datenspeicherung. Meine Aktivitäten sind nicht an ein bestimmtes Betriebssystem gebunden.
Legen Sie sich derzeit für den Hauptkernel-Zweig fest?
Sehr selten und nur, wenn mein Arbeitgeber es verlangt. Das letzte Mal vor etwa drei Jahren habe ich Patches gesendet, um den Durchsatz für gemeinsam genutzten Speicher auf Hosts zu erhöhen, die das 9p-Protokoll verwenden (ein anderer Name für dieses Unternehmen ist VirtFS). Eine wichtige Anmerkung muss hier unbedingt gemacht werden: Obwohl ich schon lange mit Linux arbeite, war ich nie ein Fan davon, das heißt, ich „atme gleichmäßig“, wie bei allem anderen auch. Insbesondere wenn mir ein Mangel auffällt, kann ich ihn höchstens einmal ansprechen. Und damit Sie dann jemandem folgen und ihn überzeugen können – das wird nicht passieren.
Ich erinnere mich, dass Sie das letzte Mal vor zehn Jahren dem Kernel-Entwicklungsstil ziemlich kritisch gegenüberstanden. Hat sich aus Ihrer Sicht (oder vielleicht aus Unternehmenssicht) etwas geändert, ist die Community reaktionsfähiger geworden oder nicht? Wenn nicht, wer ist Ihrer Meinung nach schuld?
Ich habe nie Veränderungen zum Besseren gesehen. Das Hauptproblem der Gemeinschaft ist die Ersetzung der Wissenschaft durch politische Technologien, persönliche Beziehungen, Mehrheitsmeinung, Populismus, Ratschläge „innerer Stimmen“, faule Kompromisse und alles andere als Wissenschaft. Informatik ist, was auch immer man sagen mag, in erster Linie eine exakte Wissenschaft. Und wenn jemand anfängt, seinen eigenen Wert für 2x2, der sich von 4 unterscheidet, unter der „Linux-Weg“-Flagge oder unter einer anderen Flagge zu verkünden, dann wird dies wahrscheinlich nichts anderes als Schaden anrichten.
Alle Probleme sind in erster Linie auf die Inkompetenz und mangelnde Bildung derjenigen zurückzuführen, die Entscheidungen treffen. Wenn ein Manager inkompetent ist, ist er nicht in der Lage, eine objektive und angemessene Entscheidung zu treffen. Ist er zudem unkultiviert, findet er keinen kompetenten Spezialisten, der ihn richtig berät. Mit hoher Wahrscheinlichkeit wird die Wahl auf einen Betrüger fallen, der „scheinbar richtige Dinge“ sagt. Es entsteht immer ein korruptes Umfeld um inkompetente Einzelführer. Darüber hinaus kennt die Geschichte diesbezüglich keine Ausnahmen, und die Gemeinschaft ist der deutlichste Beweis dafür.
Wie beurteilen Sie den Fortschritt in der Btrfs-Entwicklung? Hat diese FS Kinderkrankheiten beseitigt? Wie positionieren Sie es für sich – als FS „für zu Hause“ oder auch für den Firmengebrauch?
Ich habe es nicht losgeworden. Alles, was ich vor 11 Jahren erwähnt habe, ist auch heute noch relevant. Eines der Probleme mit Btrfs, das es für ernsthafte Zwecke ungeeignet macht, ist das Problem des freien Speicherplatzes. Ich spreche nicht einmal von der Tatsache, dass der Benutzer aufgefordert wird, zum Speicher für eine neue Festplatte zu laufen, wenn in jedem anderen FS viel freier Speicherplatz auf der Partition angezeigt wird. Auch die Unfähigkeit, einen Vorgang auf einem logischen Volume aufgrund fehlenden freien Speicherplatzes abzuschließen, ist nicht das Schlimmste. Das Schlimmste ist, dass ein unprivilegierter Benutzer fast immer alle Festplattenkontingente umgehen und jedem in relativ kurzer Zeit den freien Speicherplatz entziehen kann.
Es sieht so aus (getestet für Linux-Kernel 5.12). Auf einem frisch installierten System wird ein Skript gestartet, das in einer Schleife Dateien mit bestimmten Namen im Home-Verzeichnis erstellt, an bestimmten Offsets Daten darauf schreibt und diese Dateien dann löscht. Nach einer Minute der Ausführung dieses Skripts passiert nichts Ungewöhnliches. Nach fünf Minuten erhöht sich der Anteil des belegten Speicherplatzes auf der Partition leicht. Nach zwei bis drei Stunden erreicht er 50 % (bei einem Anfangswert von 15 %). Und nach fünf oder sechs Stunden Arbeit stürzt das Skript mit der Fehlermeldung „Auf der Partition ist kein freier Speicherplatz“ ab. Danach können Sie nicht einmal mehr eine 4K-Datei auf Ihre Partition schreiben.
Es kommt zu einer interessanten Situation: Am Ende haben Sie nichts auf die Partition geschrieben und der gesamte freie Speicherplatz (ca. 85 %) ist irgendwo verschwunden. Die Analyse eines Abschnitts, der einem solchen Angriff ausgesetzt ist, wird viele Baumknoten aufdecken, die nur ein Element (ein mit einem Schlüssel ausgestattetes Objekt) enthalten, das mehrere Bytes groß ist. Das heißt, der Inhalt, der zuvor 15 % des Speicherplatzes belegte, war gleichmäßig über die gesamte Partition „verschmiert“, so dass es keinen Platz zum Schreiben einer neuen Datei gab, da ihr Schlüssel größer als alle vorhandenen und der freie ist Blöcke auf der Partition sind aufgebraucht.
Darüber hinaus geschieht dies alles bereits in der grundlegenden Btrfs-Konfiguration (ohne Snapshots, Subvolumes usw.), und es spielt keine Rolle, wie Sie Dateikörper in diesem FS speichern (als „Fragmente“ in einem Baum oder als Extents). von unformatierten Blöcken) - das Endergebnis wird das gleiche sein.
Sie werden nicht in der Lage sein, andere Upstream-Dateisysteme einem solchen Angriff auszusetzen (egal, was sie Ihnen sagen). Ich habe die Ursache des Problems schon vor langer Zeit erklärt: Dies ist eine völlige Perversion des B-Tree-Konzepts in Btrfs, die es möglich macht, dass es spontan oder absichtlich degeneriert. Insbesondere unter bestimmten Belastungen „zerfällt“ Ihr Dateisystem im laufenden Betrieb selbstständig und ohne fremde Hilfe. Es ist klar, dass alle Arten von „drängenden“ Hintergrundprozessen nur auf einzelnen Desktops den Tag retten.
Auf kollektiven Servern wird ein Angreifer immer in der Lage sein, ihnen einen Schritt voraus zu sein. Der Systemadministrator kann nicht einmal feststellen, wer genau ihn gemobbt hat. Der schnellste Weg, dieses Problem in Btrfs zu beheben, besteht darin, die Struktur eines regulären B-Baums wiederherzustellen, d. h. Neugestaltung des Festplattenformats und Neuschreiben wesentlicher Teile des Btrfs-Codes. Dies wird einschließlich Debugging 8–10 Jahre dauern, vorausgesetzt, dass sich die Entwickler strikt an die Originalartikel zu den relevanten Algorithmen und Datenstrukturen gehalten und nicht das „kaputte Telefon“-Spiel gespielt haben, wie es in der „Linux“-Ära üblich (und gefördert) ist Weg".
Hier müssen wir auch die Zeit hinzufügen, die Entwickler benötigen, um dies alles zu verstehen. Hier wird es schwieriger. Auf jeden Fall reichten ihnen 10 Jahre nicht aus, um es zu verstehen. Nun ja, bis dahin kann man nicht auf ein Wunder hoffen. Es wird nicht in Form einer Montageoption geschehen, „von der Sie und ich nichts wussten“, oder in Form eines Patches, dessen Vorbereitung „nur eine Frage des Geschäftsbetriebs“ ist. Für jede dieser übereilten „Lösungen“ werde ich ein neues Degenerationsszenario vorstellen. B-Bäume sind eines meiner Lieblingsthemen und ich muss sagen, dass diese Strukturen keine Freiheiten mit sich selbst dulden!
Wie positioniere ich Btrfs für mich? Als etwas, das absolut nicht als Dateisystem bezeichnet, geschweige denn verwendet werden kann. Denn per Definition ist FS ein Betriebssystem-Subsystem, das für die effektive Verwaltung der Ressource „Festplattenspeicher“ verantwortlich ist, was wir im Fall von Btrfs nicht sehen. Stellen Sie sich vor, Sie kommen in den Laden, um eine Uhr zu kaufen, damit Sie nicht zu spät zur Arbeit kommen, und statt einer Uhr wird Ihnen ein Elektrogrill mit Timer für maximal 30 Minuten verkauft. Bei Btrfs ist die Situation also noch schlimmer.
Beim Durchsehen von Mailinglisten stoße ich oft auf die Aussage, dass eine effektive Speicherplatzverwaltung aufgrund der Billigkeit von Laufwerken nicht mehr relevant sei. Das ist völliger Unsinn. Ohne einen effektiven Speicherplatzmanager wird das Betriebssystem anfällig und unbrauchbar. Unabhängig von der Kapazität der Festplatten auf Ihrem Computer.
Ich möchte um einen Kommentar zur Einstellung der Btrfs-Unterstützung in RHEL bitten.
Hier gibt es nichts Besonderes zu kommentieren, alles ist sehr klar. Sie hatten es auch als „Technologievorschau“. Daher habe ich mir diese „Vorschau“ nicht angesehen. Lassen Sie dieses Etikett nicht für immer hängen! Aber sie können ein fehlerhaftes Designprodukt nicht mit vollem Support auf den Markt bringen. RHEL ist ein Unternehmen, das heißt, vorgeschriebene Waren-Geld-Beziehungen. Red Hat kann Benutzer nicht so schikanieren, wie sie es auf der Btrfs-Mailingliste tun. Stellen Sie sich die Situation vor: Ein Kunde, der sein hart verdientes Geld für die Festplatte und Sie auch für den Support bezahlt hat, möchte wissen, wo sein Speicherplatz geblieben ist, nachdem er nichts aufgeschrieben hat. Was werden Sie ihm darauf antworten?
Weiter. Zu den Kunden von Red Hat zählen namhafte Großbanken und Börsen. Stellen Sie sich vor, was passieren würde, wenn sie DoS-Angriffen ausgesetzt wären, die auf der erwähnten Sicherheitslücke in Btrfs basieren. Wer ist Ihrer Meinung nach dafür verantwortlich? Denjenigen, die mit dem Finger auf die Zeile der GPL-Lizenz zeigen, in der steht, dass der Autor für nichts verantwortlich ist, sage ich sofort: „Versteckt es!“ Red Hat wird antworten, und zwar so, dass es nicht genug erscheint! Aber ich weiß, dass Red Hat nicht mit solchen Problemen konfrontiert ist, da es ein besonders starkes Team von QA-Ingenieuren gibt, mit denen ich in meiner Zeit eng zusammenarbeiten durfte.
Warum unterstützen einige Unternehmen weiterhin Btrfs in ihren Unternehmensprodukten?
Bitte beachten Sie, dass das Präfix „enterprise“ im Produktnamen nicht viel bedeutet. Unter Unternehmertum versteht man ein Maß an Verantwortung, das in das Vertragsverhältnis mit dem Kunden eingebettet ist. Ich kenne nur ein Unternehmen, das auf GNU/Linux basiert – RHEL. Alles andere wird aus meiner Sicht nur als Unternehmung dargestellt, ist aber keines. Und schließlich: Wenn es eine Nachfrage nach etwas gibt, dann wird es immer ein Angebot geben (in unserem Fall ist dies die erwähnte „Unterstützung“). Es besteht Nachfrage nach absolut allem, inkl. und unbrauchbare Software. Wie eine solche Nachfrage entsteht und wer sie antreibt, ist ein anderes Thema.
Daher würde ich keine voreiligen Schlussfolgerungen ziehen, nachdem Gerüchten zufolge Facebook Btrfs auf seinen Servern eingesetzt hat. Darüber hinaus würde ich aus den oben genannten Gründen empfehlen, die Adressen dieser Server sorgfältig geheim zu halten.
Warum wurde in letzter Zeit so viel Aufwand in die Bereinigung des XFS-Codes gesteckt? Schließlich handelt es sich zunächst um ein Dateisystem eines Drittanbieters, und ext4 ist seit langem stabil und weist Kontinuität zu früheren, ebenso stabilen Versionen auf. Welches Interesse hat Red Hat an XFS? Ist es sinnvoll, zwei Dateisysteme mit ähnlichem Zweck – ext4 und XFS – aktiv zu entwickeln?
Ich kann mich nicht erinnern, was die Motivation dafür war. Es ist durchaus möglich, dass die Initiative von Red Hat-Kunden ausging. Ich erinnere mich, dass Untersuchungen dieser Art durchgeführt wurden: Auf einigen Dateisystemen von Upstream wurde eine gigantische Anzahl von Objekten auf High-End-Laufwerken der neuen Generation erstellt. Den Ergebnissen zufolge verhielt sich XFS besser als ext4. Also begannen sie, es als das vielversprechendste zu bewerben. Auf jeden Fall würde ich hier nichts Sensationelles suchen.
Für mich ist es, als hätten sie eine Ahle durch Seife ersetzt. Es macht keinen Sinn, ext4 und XFS zu entwickeln. Sowohl parallel als auch beliebig zur Auswahl. Daraus wird nichts Gutes entstehen. Obwohl es in der Natur oft Situationen gibt, in denen viel Wachstumspotenzial vorhanden ist, aber kein Raum zum Wachsen vorhanden ist. In diesem Fall entstehen verschiedene bizarr hässliche Neubildungen, auf die jeder mit dem Finger zeigt („Oh, schau, was wirst du in diesem Leben nicht sehen!“).
Glauben Sie, dass das Problem der Layer-Verletzung (im negativen Sinne) mit der Einführung der Verschlüsselungsfunktionen in ext4, F2FS (ganz zu schweigen von RAID in Btrfs) gelöst wurde?
Im Allgemeinen ist die Einführung von Ebenen und die Entscheidung über deren Nichtverletzung in der Regel eine Frage der Politik, und ich verpflichte mich nicht, hier zu irgendetwas Stellung zu nehmen. Die objektiven Aspekte der Schichtverletzung sind für niemanden von Interesse, aber wir können einige davon am Beispiel der Verletzung „von oben“ betrachten, nämlich der Implementierung von Funktionen, die bereits auf der Blockschicht vorhanden sind, im FS. Ein solcher „Verstoß“ ist nur in seltenen Ausnahmen gerechtfertigt. Für jeden solchen Fall müssen Sie zunächst zwei Dinge nachweisen: dass es wirklich notwendig ist und dass das Design des Systems dadurch nicht beeinträchtigt wird.
Beispielsweise ist es sinnvoll, die Spiegelung, die traditionell eine Aktivität der Blockschicht war, auf Dateisystemebene zu implementieren. Aus verschiedenen Gründen. Beispielsweise kommt es auf Festplattenlaufwerken zu einer „stillen“ Datenbeschädigung (Bitfäule). Dies ist der Fall, wenn das Gerät ordnungsgemäß funktioniert, die Blockdaten jedoch durch den Einfluss eines harten Gammaquants, das von einem entfernten Quasar usw. emittiert wird, unerwartet beschädigt werden. Das Schlimmste ist, wenn sich herausstellt, dass es sich bei diesem Block um einen FS-Systemblock (Superblock, Bitmap-Block, Speicherbaumknoten usw.) handelt, da dies mit Sicherheit zu einer Kernel-Panik führt.
Bitte beachten Sie, dass die von der Blockschicht angebotenen Spiegelungen (sog. RAID 1) Sie nicht vor diesem Problem bewahren. Na ja, wirklich: Sollte jemand die Prüfsummen überprüfen und im Fehlerfall die Replik auslesen? Darüber hinaus ist es sinnvoll, nicht nur alles, sondern nur die Metadaten zu spiegeln. Einige wichtige Daten (z. B. ausführbare Dateien kritischer Anwendungen) können als Metadaten gespeichert werden. In diesem Fall erhalten sie die gleichen Sicherheitsgarantien. Es ist sinnvoll, den Schutz der verbleibenden Daten anderen Subsystemen (vielleicht sogar Benutzeranwendungen) anzuvertrauen – wir haben dafür alle notwendigen Voraussetzungen geschaffen.
Solche „sparsamen“ Spiegel haben eine Daseinsberechtigung und können nur auf Dateisystemebene effektiv organisiert werden. Andernfalls führt eine Layering-Verletzung dazu, dass ein Subsystem mit dupliziertem Code überladen wird, um einige mikroskopische Vorteile zu erzielen. Ein markantes Beispiel hierfür ist die Implementierung von RAID-5 mittels FS. Solche Lösungen (eigenes RAID/LVM im Dateisystem) machen Letzteres architektonisch zunichte. Hierbei ist auch zu beachten, dass Layering-Verstöße von verschiedenen Arten von Marketingbetrügern „in Gang gesetzt“ werden. In Ermangelung jeglicher Ideen wird den Subsystemen Funktionalität hinzugefügt, die auf benachbarten Ebenen längst implementiert ist, als neues äußerst nützliches Feature dargestellt und aktiv gepusht.
Reiser4 wurde vorgeworfen, gegen die Level „von unten“ verstoßen zu haben. Aufgrund der Tatsache, dass das Dateisystem nicht wie alle anderen monolithisch, sondern modular aufgebaut ist, wurde eine unbegründete Annahme getroffen, dass es das tut, was die darüber liegende Ebene (VFS) tun sollte.
Kann man über den Tod von ReiserFS v3.6 und beispielsweise JFS sprechen? In letzter Zeit haben sie im Kern kaum Beachtung gefunden. Sind sie veraltet?
Hier müssen wir definieren, was der Tod eines Softwareprodukts bedeutet. Einerseits werden sie erfolgreich eingesetzt (dafür sind sie schließlich geschaffen), was bedeutet, dass sie leben. Andererseits kann ich nicht für JFS sprechen (ich weiß nicht viel), aber ReiserFS (v3) lässt sich nur sehr schwer an neue Trends anpassen (in der Praxis getestet). Dies bedeutet, dass Entwickler in Zukunft nicht mehr darauf achten werden, sondern auf diejenigen, die sich leichter anpassen lassen. Von dieser Seite aus stellt sich heraus, dass es in architektonischer Hinsicht leider tot ist. Ich würde den Begriff „moralisch veraltet“ überhaupt nicht manipulieren. Das gilt zum Beispiel gut für einen Kleiderschrank, nicht aber für Softwareprodukte. Es gibt ein Konzept von Minderwertigkeit und Überlegenheit in etwas. Ich kann absolut sagen, dass ReserFS v3 Reiser4 mittlerweile in allem unterlegen ist, aber in einigen Arten von Workload ist es allen anderen Upstream-FSs überlegen.
Kennen Sie die Entwicklung von FS Tux3 und HAMMER/HAMMER2 (FS für DragonFly BSD)?
Ja, wir wissen. Bei Tux3 interessierte mich einst die Technik ihrer Snapshots (die sogenannten „Versionszeiger“), bei Reiser4 werden wir aber höchstwahrscheinlich einen anderen Weg gehen. Ich habe schon lange darüber nachgedacht, Snapshots zu unterstützen und habe mich noch nicht entschieden, wie ich sie für einfache Reiser4-Volumes umsetzen soll. Tatsache ist, dass die von Ohad Rodeh vorgeschlagene neue „faule“ Referenzzählertechnik nur für B-Bäume funktioniert. Wir haben sie nicht. Für die Datenstrukturen, die in Reiesr4 verwendet werden, sind keine „faulen“ Zähler definiert. Um sie einzuführen, müssen bestimmte algorithmische Probleme gelöst werden, mit denen sich noch niemand befasst hat.
Laut HAMMER: Ich habe einen Artikel des Erstellers gelesen. Nicht interessiert. Wieder B-Bäume. Diese Datenstruktur ist hoffnungslos veraltet. Wir haben es im letzten Jahrhundert aufgegeben.
Wie beurteilen Sie die wachsende Nachfrage nach Netzwerk-Cluster-FSs wie CephFS/GlusterFS/usw.? Bedeutet diese Forderung eine Verschiebung der Prioritäten der Entwickler hin zu Netzwerk-FS und eine unzureichende Berücksichtigung lokaler FS?
Ja, eine solche Verschiebung der Prioritäten hat stattgefunden. Die Entwicklung lokaler Dateisysteme stagniert. Leider ist es heutzutage ziemlich schwierig, etwas Bedeutendes für lokale Volumina zu tun, und nicht jeder kann es tun. Niemand möchte in seine Entwicklung investieren. Das ist ungefähr so, als würde man eine kommerzielle Organisation bitten, Geld für mathematische Forschung bereitzustellen – sie wird Sie ohne jegliche Begeisterung fragen, wie Sie mit einem neuen Theorem Geld verdienen können. Jetzt ist ein lokaler FS etwas, das wie von Zauberhand „out of the box“ erscheint und „immer funktionieren sollte“, und wenn es nicht funktioniert, löst es unadressiertes Murren aus wie: „Ja, was denken die denn?“
Daher mangelt es der lokalen FS an Aufmerksamkeit, obwohl in diesem Bereich noch viel zu tun ist. Und ja, jeder hat sich dem verteilten Speicher zugewandt, der auf der Grundlage bereits vorhandener lokaler Dateisysteme aufgebaut ist. Es ist jetzt sehr in Mode. Der Begriff „Big Data“ löst bei vielen einen Adrenalinstoß aus und bringt ihn mit Konferenzen, Workshops, hohen Gehältern usw. in Verbindung.
Wie sinnvoll ist es grundsätzlich, das Netzwerkdateisystem im Kernel-Space statt im User-Space zu implementieren?
Ein sehr vernünftiger Ansatz, der bisher noch nirgendwo umgesetzt wurde. Generell ist die Frage, in welchem Raum ein Netzwerkdateisystem implementiert werden sollte, ein „zweischneidiges Schwert“. Schauen wir uns ein Beispiel an. Der Client hat Daten auf einem Remote-Computer aufgezeichnet. Sie landeten in Form schmutziger Seiten in ihrem Seitencache. Dies ist die Aufgabe eines „Thin Gateway“-Netzwerkdateisystems im Kernel-Space. Dann wird Sie das Betriebssystem früher oder später auffordern, diese Seiten auf die Festplatte zu schreiben, um sie freizugeben. Dann kommt das IO-weiterleitende (sendende) Netzwerk-FS-Modul ins Spiel. Es bestimmt, zu welchem Serverrechner (Serverknoten) diese Seiten gehen.
Dann übernimmt der Netzwerk-Stack (und wird, wie wir wissen, im Kernel-Space implementiert). Als nächstes empfängt der Serverknoten dieses Paket mit Daten oder Metadaten und weist das Backend-Speichermodul (d. h. den lokalen FS, der im Kernel-Space arbeitet) an, all diese Dinge aufzuzeichnen. Deshalb haben wir die Frage darauf reduziert, wo die Module „Senden“ und „Empfangen“ funktionieren sollen. Wenn eines dieser Module im Benutzerbereich ausgeführt wird, führt dies unweigerlich zu einem Kontextwechsel (aufgrund der Notwendigkeit, Kernel-Dienste zu verwenden). Die Anzahl solcher Schalter hängt von den Implementierungsdetails ab.
Wenn es viele solcher Switches gibt, sinkt der Speicherdurchsatz (I/O-Leistung). Wenn Ihr Backend-Speicher aus langsamen Festplatten besteht, werden Sie keinen nennenswerten Rückgang bemerken. Wenn Sie jedoch über schnelle Festplatten (SSD, NVRAM usw.) verfügen, wird der Kontextwechsel bereits zum „Flaschenhals“ und durch die Einsparung des Kontextwechsels kann die Leistung erheblich gesteigert werden. Die übliche Möglichkeit, Geld zu sparen, besteht darin, Module in den Kernel-Bereich zu verschieben. Wir haben beispielsweise festgestellt, dass die Verlagerung des 9p-Servers von QEMU in den Kernel auf dem Host-Rechner zu einer Verdreifachung der VirtFS-Leistung führt.
Dies ist natürlich kein Netzwerk-FS, aber es spiegelt das Wesen der Dinge vollständig wider. Der Nachteil dieser Optimierung sind Portabilitätsprobleme. Für einige mag Letzteres von entscheidender Bedeutung sein. GlusterFS hat beispielsweise überhaupt keine Module im Kernel. Dank dessen funktioniert es jetzt auf vielen Plattformen, einschließlich NetBSD.
Welche Konzepte könnten lokale FS von Netzwerk-FS übernehmen und umgekehrt?
Heutzutage haben Netzwerk-FSs in der Regel Add-Ons gegenüber lokalen FSs, daher verstehe ich nicht ganz, wie man sich etwas von letzteren leihen kann. Nun ja, stellen wir uns ein Unternehmen mit 4 Mitarbeitern vor, in dem jeder sein eigenes Ding macht: Einer verteilt, ein anderer sendet, der Dritte empfängt, der Vierte lagert. Und die Frage, was sich das Unternehmen von seinem Mitarbeiter leihen kann, der es lagert, klingt irgendwie falsch (das, was es sich von ihm hätte leihen können, hat es ja schon längst).
Aber lokale FSs können viel von Netzwerk-FSs lernen. Zunächst sollten Sie von ihnen lernen, wie man logische Volumes auf hohem Niveau aggregiert. Nun das sogenannte „Fortgeschrittene“ lokale Dateisysteme aggregieren logische Volumes ausschließlich mithilfe der „Virtual Device“-Technologie, die von LVM übernommen wurde (dieselbe infektiöse Layering-Verletzung, die erstmals in ZFS implementiert wurde). Mit anderen Worten: Die Übersetzung virtueller Adressen (Blocknummern) in reale Adressen und zurück erfolgt auf einer niedrigen Ebene (d. h. nachdem das Dateisystem eine E/A-Anfrage ausgegeben hat).
Bitte beachten Sie, dass das Hinzufügen und Entfernen von Geräten zu logischen Volumes (nicht Spiegeln), die auf der Blockebene angeordnet sind, zu Problemen führt, über die Anbieter solcher „Funktionen“ bescheiden schweigen. Ich spreche von Fragmentierung auf realen Geräten, die monströse Werte erreichen kann, während auf einem virtuellen Gerät alles in Ordnung ist. Allerdings interessieren sich nur wenige Menschen für virtuelle Geräte: Jeder interessiert sich dafür, was auf Ihren realen Geräten passiert. Aber ZFS-ähnliche FS (sowie alle FS in Verbindung mit LVM) funktionieren nur mit virtuellen Festplattengeräten (weisen Sie virtuelle Festplattenadressen aus den freien zu, defragmentieren Sie diese virtuellen Geräte usw.). Und sie haben keine Ahnung, was auf echten Geräten passiert!
Stellen Sie sich nun vor, dass auf dem virtuellen Gerät keine Fragmentierung vorliegt (das heißt, dass dort nur ein einziger riesiger Extent vorhanden ist), dass Sie eine Festplatte zu Ihrem logischen Volume hinzufügen und dann eine weitere zufällige Festplatte aus Ihrem logischen Volume entfernen und diese dann neu ausgleichen. Und so oft. Es ist nicht schwer, sich vorzustellen, dass Sie auf dem virtuellen Gerät immer noch das gleiche Maß an Leben haben werden, auf realen Geräten jedoch nichts Gutes.
Das Schlimmste ist, dass Sie nicht einmal in der Lage sind, diese Situation zu korrigieren! Hier können Sie lediglich das Dateisystem auffordern, das virtuelle Gerät zu defragmentieren. Aber sie wird Ihnen sagen, dass dort alles großartig ist – es gibt nur ein Ausmaß, die Fragmentierung ist Null und es kann nicht besser sein! Daher sind auf Blockebene angeordnete logische Volumes nicht für das wiederholte Hinzufügen/Entfernen von Geräten vorgesehen. Das Gute daran ist, dass Sie ein logisches Volume nur einmal auf Blockebene zusammenstellen, es dem Dateisystem übergeben und dann nichts weiter damit tun müssen.
Darüber hinaus ermöglicht die Kombination unabhängiger FS+LVM-Subsysteme nicht, die unterschiedliche Beschaffenheit der Laufwerke zu berücksichtigen, aus denen logische Volumes aggregiert werden. Angenommen, Sie haben ein logisches Volume aus Festplatten und Solid-State-Geräten zusammengestellt. Aber dann ist bei Ersterem eine Defragmentierung erforderlich, bei Letzterem nicht. Für Letzteres müssen Sie Löschanfragen stellen, für Ersteres jedoch nicht usw. Allerdings ist es in dieser Kombination recht schwierig, eine solche Selektivität nachzuweisen.
Beachten Sie, dass sich die Situation nach dem Erstellen eines eigenen LVM im Dateisystem nicht wesentlich verbessert. Darüber hinaus machen Sie damit der Aussicht, es in Zukunft jemals zu verbessern, ein Ende. Das ist sehr schlecht. Auf derselben Maschine können verschiedene Laufwerkstypen vorhanden sein. Und wenn das Dateisystem nicht zwischen ihnen unterscheidet, wer dann?
Ein weiteres Problem lauert auf die sogenannten. „Write-Anywhere“-Dateisysteme (dazu gehört auch Reiser4, wenn Sie beim Mounten das entsprechende Transaktionsmodell angegeben haben). Solche Dateisysteme müssen Defragmentierungstools bereitstellen, die in ihrer Leistungsfähigkeit beispiellos sind. Und der Low-Level-Volume-Manager hilft hier nicht weiter, sondern stört nur. Tatsache ist, dass Ihr FS mit einem solchen Manager eine Karte der freien Blöcke nur eines Geräts speichert – eines virtuellen. Dementsprechend können Sie nur ein virtuelles Gerät defragmentieren. Das bedeutet, dass Ihr Defragmentierer sehr lange auf einem riesigen einzigen Bereich virtueller Adressen arbeiten wird.
Und wenn viele Benutzer zufällige Überschreibungen durchführen, wird der nützliche Effekt eines solchen Defragmentierers auf Null reduziert. Ihr System wird unweigerlich langsamer und Sie müssen angesichts der enttäuschenden Diagnose „kaputtes Design“ nur noch die Hände falten. Mehrere Defragmentierer, die im selben Adressraum ausgeführt werden, stören sich nur gegenseitig. Eine völlig andere Sache ist es, wenn Sie für jedes reale Gerät eine eigene Karte freier Blöcke verwalten. Dadurch wird der Defragmentierungsprozess effektiv parallelisiert.
Dies ist jedoch nur möglich, wenn Sie über einen logischen Volume-Manager auf hoher Ebene verfügen. Lokale Dateisysteme mit solchen Managern gab es bisher nicht (zumindest weiß ich nichts davon). Nur Netzwerkdateisysteme (z. B. GlusterFS) verfügten über solche Manager. Ein weiteres sehr wichtiges Beispiel ist das Dienstprogramm zur Überprüfung der Datenträgerintegrität (fsck). Wenn Sie für jedes Subvolume eine eigene unabhängige Karte freier Blöcke speichern, kann das Verfahren zur Überprüfung eines logischen Volumes effektiv parallelisiert werden. Mit anderen Worten: Logische Volumes mit hochrangigen Managern lassen sich besser skalieren.
Darüber hinaus können Sie mit Low-Level-Volume-Managern keine vollwertigen Snapshots organisieren. Mit LVM- und ZFS-ähnlichen Dateisystemen können Sie nur lokale Snapshots erstellen, nicht jedoch globale Snapshots. Mit lokalen Snapshots können Sie nur normale Dateivorgänge sofort rückgängig machen. Und dort wird niemand Vorgänge mit logischen Volumes (Hinzufügen/Entfernen von Geräten) rückgängig machen. Schauen wir uns das anhand eines Beispiels an. Irgendwann, wenn Sie über ein logisches Volume aus zwei Geräten A und B verfügen, das 100 Dateien enthält, erstellen Sie einen Snapshot des Systems S und erstellen dann weitere hundert Dateien.
Danach fügen Sie Gerät C zu Ihrem Volume hinzu und führen schließlich ein Rollback Ihres Systems auf Snapshot S durch. Frage: Wie viele Dateien und Geräte enthält Ihr logisches Volume nach dem Rollback auf S? Wie Sie vielleicht vermutet haben, wird es 100 Dateien geben, aber es wird 3 Geräte geben – das sind die gleichen Geräte A, B und C, obwohl es zum Zeitpunkt der Erstellung des Snapshots nur zwei Geräte im System gab (A und B). ). Der Vorgang zum Hinzufügen von Gerät C wurde nicht rückgängig gemacht, und wenn Sie jetzt Gerät C vom Computer entfernen, werden Ihre Daten beschädigt. Daher müssen Sie vor dem Löschen zunächst einen kostspieligen Vorgang durchführen, um das Gerät aus dem logischen Neuausgleichsvolume zu entfernen verteilt alle Daten von Gerät C auf die Geräte A und B. Wenn Ihr FS jedoch globale Snapshots unterstützen würde, wäre eine solche Neuverteilung nicht erforderlich, und nach einem sofortigen Rollback auf S könnten Sie Gerät C sicher vom Computer entfernen.
Globale Snapshots sind also gut, weil sie es Ihnen ermöglichen, das kostspielige Entfernen (Hinzufügen) eines Geräts von einem logischen Volume (zu einem logischen Volume) mit einer großen Datenmenge zu vermeiden (natürlich, wenn Sie daran denken, einen „Snapshot“ Ihres Systems zu erstellen). Zur richtigen Zeit). Ich möchte Sie daran erinnern, dass das Erstellen von Snapshots und das Zurücksetzen des Dateisystems darauf sofortige Vorgänge sind. Möglicherweise stellt sich die Frage: Wie ist es überhaupt möglich, einen Vorgang auf einem logischen Volume, der drei Tage gedauert hat, sofort rückgängig zu machen? Aber es ist möglich! Vorausgesetzt, Ihr Dateisystem ist richtig konzipiert. Die Idee zu solchen „3D-Schnappschüssen“ kam mir vor drei Jahren und letztes Jahr habe ich diese Technik patentieren lassen.
Das nächste, was lokale FSs von Netzwerk-FSs lernen sollten, ist, Metadaten auf separaten Geräten auf die gleiche Weise zu speichern, wie Netzwerk-FSs sie auf separaten Maschinen (den sogenannten Metadatenservern) speichern. Es gibt Anwendungen, die hauptsächlich mit Metadaten arbeiten, und diese Anwendungen können erheblich beschleunigt werden, indem die Metadaten auf teuren Hochleistungsspeichergeräten abgelegt werden. Mit der FS+LVM-Kombination können Sie eine solche Selektivität nicht nachweisen: LVM weiß nicht, was sich in dem Block befindet, den Sie ihm übergeben haben (Daten dort oder Metadaten).
Die Implementierung Ihres eigenen Low-Level-LVM im FS wird Ihnen im Vergleich zur FS+LVM-Kombination keinen großen Nutzen bringen, aber was Sie sehr gut tun können, ist, den FS so zu überladen, dass es später unmöglich wird, mit seinem Code zu arbeiten. ZFS und Btrfs, die mit virtuellen Geräten überstürzt sind, sind allesamt klare Beispiele dafür, wie Layering-Verstöße das System in architektonischer Hinsicht zerstören. Warum bin ich also das alles? Darüber hinaus ist es nicht erforderlich, einen eigenen Low-Level-LVM im Dateisystem zu installieren. Stattdessen müssen Sie Geräte auf hoher Ebene zu logischen Volumes zusammenfassen, wie dies bei einigen Netzwerkdateisystemen mit verschiedenen Maschinen (Speicherknoten) der Fall ist. Es ist wahr, dass sie dies auf widerliche Weise tun, weil sie schlechte Algorithmen verwenden.
Beispiele für absolut schreckliche Algorithmen sind der DHT-Übersetzer im GlusterFS-Dateisystem und die sogenannte CRUSH-Map im Ceph-Dateisystem. Keiner der Algorithmen, die ich gesehen habe, hat mich in Bezug auf Einfachheit und gute Skalierbarkeit zufrieden gestellt. Also musste ich mir die Algebra merken und alles selbst erfinden. Als ich 2015 mit Bundles anstelle von Hash-Funktionen experimentierte, kam ich auf etwas, das zu mir passte, und ließ es patentieren. Jetzt kann ich sagen, dass der Versuch, dies alles in die Tat umzusetzen, erfolgreich war. Ich sehe keine Probleme mit der Skalierbarkeit des neuen Ansatzes.
Ja, jedes Subvolume erfordert eine separate Struktur, z. B. einen Superblock im Speicher. Ist das sehr beängstigend? Im Allgemeinen weiß ich nicht, wer „den Ozean zum Kochen bringen“ und logische Volumes mit Hunderttausenden oder mehr Geräten auf einem lokalen Computer erstellen wird. Wenn mir das jemand erklären kann, wäre ich sehr dankbar. Mittlerweile ist das für mich Marketing-Bullshit.
Wie haben sich Änderungen im Kernel-Blockgeräte-Subsystem (z. B. das Erscheinen von blk-mq) auf die Anforderungen für die FS-Implementierung ausgewirkt?
Sie hatten keine Auswirkungen. Ich weiß nicht, was auf der Blockschicht passieren würde, was den Entwurf eines neuen FS erforderlich machen würde. Die Interaktionsschnittstelle dieser Subsysteme ist sehr schlecht. Auf der Treiberseite sollte der FS nur vom Erscheinen neuer Laufwerkstypen betroffen sein, an die zuerst die Blockebene und dann der FS angepasst werden (für reiser4 bedeutet dies das Erscheinen neuer Plugins).
Bedeutet das Aufkommen neuer Medientypen (z. B. SMR oder die Allgegenwärtigkeit von SSDs) grundlegend neue Herausforderungen für das Dateisystemdesign?
Ja. Und das sind normale Anreize für die Entwicklung von FS. Herausforderungen können unterschiedlich und völlig unerwartet sein. Ich habe zum Beispiel von Laufwerken gehört, bei denen die Geschwindigkeit eines E/A-Vorgangs stark von der Größe eines Datenelements und seinem Offset abhängt. Unter Linux, wo die Größe des FS-Blocks die Seitengröße nicht überschreiten darf, zeigt ein solches Laufwerk standardmäßig nicht seine volle Leistungsfähigkeit. Wenn Ihr Dateisystem jedoch richtig konzipiert ist, besteht die Chance, noch viel mehr daraus zu machen.
Wie viele Personen außer Ihnen arbeiten derzeit mit dem Reiser4-Code?
Weniger als mir lieb wäre, aber ich erlebe auch keinen akuten Ressourcenmangel. Ich bin mit dem Entwicklungstempo von Reiser4 mehr als zufrieden. Ich werde nicht „Pferde treiben“ – das ist nicht der richtige Bereich. Hier gilt: „Wer leiser fährt, fährt weiter!“ Ein modernes Dateisystem ist das komplexeste Kernel-Subsystem, dessen falsche Designentscheidungen nachfolgende Jahre menschlicher Arbeit zunichte machen können.
Indem ich Freiwillige anbiete, etwas umzusetzen, garantiere ich immer, dass die Bemühungen mit Sicherheit zum richtigen Ergebnis führen, was bei ernsthaften Bedürfnissen gefragt sein kann. Wie Sie wissen, kann es nicht viele solcher Garantien gleichzeitig geben. Gleichzeitig kann ich „Figuren“ nicht ertragen, die schamlos „Funktionen“ offensichtlich unbrauchbarer Software bewerben, Hunderte von Benutzern und Entwicklern täuschen und gleichzeitig auf Kernel-Gipfeln sitzen und lächeln.
Hat ein Unternehmen seine Bereitschaft bekundet, die Entwicklung von Reiser4 zu unterstützen?
Ja, es gab solche Vorschläge, inkl. und von einem großen Anbieter. Aber dafür musste ich in ein anderes Land ziehen. Leider bin ich nicht mehr 30 Jahre alt, ich kann mich nicht losreißen und gleich beim ersten Anpfiff gehen.
Welche Funktionen fehlen derzeit in Reiser4?
Für einfache Volumes gibt es keine Funktion zum Ändern der Größe, ähnlich wie in ReiserFS (v3). Darüber hinaus würden Dateioperationen mit dem DIRECT_IO-Flag nicht schaden. Als nächstes möchte ich in der Lage sein, ein Volume in „semantische Subvolumes“ aufzuteilen, die keine feste Größe haben und als unabhängige Volumes bereitgestellt werden können. Diese Aufgaben eignen sich gut für Anfänger, die sich an der „echten Sache“ versuchen möchten.
Und schließlich möchte ich logische Netzwerkvolumes mit einfacher Implementierung und Verwaltung haben (moderne Algorithmen ermöglichen dies bereits). Was Reiser4 aber definitiv nie haben wird, sind RAID-Z, Scrubs, Freiraum-Caches, 128-Bit-Variablen und anderer Marketing-Unsinn, der vor dem Hintergrund der Ideenlosigkeit der Entwickler mancher Dateisysteme entstanden ist.
Kann alles, was benötigt wird, durch Plugins umgesetzt werden?
Wenn wir nur von Schnittstellen und Plugins (Modulen) sprechen, die sie implementieren, dann nicht von allem. Wenn man aber auch Beziehungen auf diesen Schnittstellen einführt, dann hat man unter anderem die Konzepte höherer Polymorphismen, mit denen man schon auskommen kann. Stellen Sie sich vor, Sie hätten hypothetisch ein objektorientiertes Laufzeitsystem eingefroren, den Wert des Anweisungszeigers so geändert, dass er auf ein anderes Plugin verweist, das dieselbe X-Schnittstelle implementiert, und dann das System wieder eingefroren, sodass es weiterhin ausgeführt wird.
Wenn der Endbenutzer eine solche „Ersetzung“ nicht bemerkt, sagen wir, dass das System einen Polymorphismus nullter Ordnung in der X-Schnittstelle aufweist (oder dass das System in der X-Schnittstelle heterogen ist, was dasselbe ist). Wenn Sie nun nicht nur über eine Reihe von Schnittstellen verfügen, sondern auch über Beziehungen zu diesen (Schnittstellengraphen), können Sie Polymorphismen höherer Ordnung einführen, die die Heterogenität des Systems bereits in der „Nachbarschaft“ einer beliebigen Schnittstelle charakterisieren. Ich habe eine solche Klassifizierung schon vor langer Zeit eingeführt, aber leider ist es nie dazu gekommen.
Mit Hilfe von Plugins und solchen höheren Polymorphismen können Sie also alle bekannten Funktionen beschreiben und auch diejenigen „vorhersagen“, die noch nie erwähnt wurden. Ich konnte dies nicht streng beweisen, kenne aber auch noch kein Gegenbeispiel. Generell erinnerte mich diese Frage an das „Erlanger Programm“ von Felix Klein. Einst versuchte er, die gesamte Geometrie als einen Zweig der Algebra (insbesondere der Gruppentheorie) darzustellen.
Nun zur Hauptfrage: Wie läuft es mit der Beförderung von Reiser4 zum Hauptkern? Gab es Veröffentlichungen zur Architektur dieses Dateisystems, über die Sie im letzten Interview gesprochen haben? Wie relevant ist diese Frage aus Ihrer Sicht?
Generell fordern wir seit drei Jahren die Aufnahme in die Hauptniederlassung. Reisers letzter Kommentar im öffentlichen Thread, in dem die Pull-Anfrage gestellt wurde, blieb unbeantwortet. Alle weiteren Fragen sind also nicht für uns. Ich persönlich verstehe nicht, warum wir in ein bestimmtes Betriebssystem „verschmelzen“ müssen. Unter Linux konvergierte das Licht nicht wie ein Keil. Es gibt also ein separates Repository, in dem es mehrere Branch-Ports für verschiedene Betriebssysteme gibt. Wer es braucht, kann den entsprechenden Port klonen und damit machen, was er will (natürlich im Rahmen der Lizenz). Nun, wenn jemand es nicht braucht, dann ist es nicht mein Problem. An dieser Stelle schlage ich vor, die Frage der „Hochstufung in den Haupt-Linux-Kernel“ als geklärt zu betrachten.
Veröffentlichungen zur FS-Architektur sind relevant, aber bisher habe ich nur Zeit für meine neuen Ergebnisse gefunden, die meiner Meinung nach eine höhere Priorität haben. Eine andere Sache ist, dass ich Mathematiker bin und in der Mathematik jede Veröffentlichung eine Zusammenfassung von Theoremen und ihren Beweisen ist. Dort etwas ohne Beweise zu veröffentlichen, ist ein Zeichen von schlechtem Geschmack. Wenn ich eine Aussage über die Architektur des FS gründlich beweise oder widerlege, dann wird das Ergebnis solche Haufen sein, dass es ziemlich schwierig sein wird, durchzukommen. Wer braucht es? Dies ist wahrscheinlich der Grund, warum weiterhin alles in seiner alten Form bleibt – der Quellcode und die Kommentare dazu.
Was gab es in Reiser4 in den letzten Jahren Neues?
Die lang erwartete Stabilität ist endlich eingetreten. Einer der letzten, der auftauchte, war ein Fehler, der zu „nicht löschbaren“ Verzeichnissen führte. Die Schwierigkeit bestand darin, dass es nur vor dem Hintergrund von Namens-Hash-Kollisionen und bei einer bestimmten Position von Verzeichniseinträgen in einem Baumknoten auftrat. Für die Produktion kann ich Reiser4 jedoch immer noch nicht empfehlen: Hierfür sind einige Arbeiten mit aktiver Interaktion mit den Administratoren des Produktionssystems erforderlich.
Endlich ist es uns gelungen, unsere langjährige Idee – unterschiedliche Transaktionsmodelle – umzusetzen. Bisher lief auf Reiser4 nur ein fest codiertes Macdonald-Reiser-Modell. Dies führte zu Designproblemen. Insbesondere sind Snapshots in einem solchen Transaktionsmodell nicht möglich – sie werden durch eine atomare Komponente namens „OVERWRITE SET“ beschädigt. Reiser4 unterstützt derzeit drei Transaktionsmodelle. In einer davon (Write-Anywhere) enthält die atomare Komponente OVERWRITE SET nur Systemseiten (Bilder von Festplatten-Bitmaps usw.), die nicht „fotografiert“ werden können (das Henne-Ei-Problem).
So können die Bilder nun bestmöglich umgesetzt werden. In einem anderen Transaktionsmodell gehen alle geänderten Seiten nur an den OVERWRITE SET (d. h. es handelt sich im Wesentlichen um reines Journaling). Dieses Modell ist für diejenigen gedacht, die sich über die schnelle Fragmentierung von Reiser4-Partitionen beschwert haben. Jetzt fragmentiert Ihre Partition in diesem Modell nicht schneller als mit ReiserFS (v3). Alle drei existierenden Modelle garantieren mit einigen Vorbehalten die Atomizität von Operationen, aber auch Modelle mit Verlust der Atomizität und der Beibehaltung nur der Integrität des Abschnitts können nützlich sein. Solche Modelle können für Anwendungen aller Art (Datenbanken etc.) nützlich sein, die bereits einige dieser Funktionen übernommen haben. Es ist sehr einfach, diese Modelle zu Reiser4 hinzuzufügen, aber ich habe es nicht getan, weil mich niemand danach gefragt hat und ich persönlich es nicht brauche.
Es erschienen Metadaten-Prüfsummen, die ich kürzlich durch „sparsame“ Spiegel (immer noch instabiles Material) ergänzt habe. Wenn die Prüfsumme eines Blocks fehlschlägt, liest Reiser4 sofort den entsprechenden Block vom Replikatgerät. Beachten Sie, dass ZFS und Btrfs dies nicht können: Das Design lässt dies nicht zu. Dort müssen Sie einen speziellen Hintergrundscanvorgang namens „Scrub“ ausführen und warten, bis der problematische Block erreicht ist. Programmierer nennen solche Ereignisse im übertragenen Sinne „Krücken“.
Und schließlich sind heterogene logische Volumes aufgetaucht, die alles bieten, was ZFS, Btrfs, Block Layer sowie FS+LVM-Kombinationen im Prinzip nicht bieten können – parallele Skalierung, O(1)-Disk-Adresszuweisung, transparente Datenmigration zwischen Subvolumes. Letzteres verfügt auch über eine Benutzeroberfläche. Jetzt können Sie die aktuellsten Daten ganz einfach auf das leistungsstärkste Laufwerk Ihres Volumes verschieben.
Darüber hinaus ist es möglich, alle schmutzigen Seiten dringend auf ein solches Laufwerk zu leeren, wodurch Anwendungen, die häufig fsync(2) aufrufen, erheblich beschleunigt werden. Ich stelle fest, dass die Block-Layer-Funktionalität namens bcache überhaupt keine solche Handlungsfreiheit bietet. Neue logische Datenträger basieren auf meinen Algorithmen (es gibt entsprechende Patente). Die Software ist bereits recht stabil, es ist durchaus möglich, sie auszuprobieren, die Leistung zu messen usw. Der einzige Nachteil besteht darin, dass Sie die Volume-Konfiguration zunächst manuell aktualisieren und irgendwo speichern müssen.
Bisher konnte ich meine Ideen zu 10 Prozent umsetzen, mir ist jedoch das gelungen, was ich als das Schwierigste empfand: die Verbindung logischer Volumes mit einem Flash-Verfahren, das alle verzögerten Aktionen in reiser4 ausführt. Das alles ist noch im experimentellen „format41“-Zweig.
Besteht Reiser4 xftests?
Zumindest war das bei mir der Fall, als ich die letzte Veröffentlichung vorbereitete.
Ist es grundsätzlich möglich, Reiser4 mithilfe von Plugins zu einem Netzwerk-(Cluster-)FS zu machen?
Es ist möglich und sogar notwendig! Wenn Sie eine Netzwerkdatei auf der Grundlage eines ordnungsgemäß konzipierten lokalen Dateisystems erstellen, wird das Ergebnis sehr beeindruckend sein! In modernen Netzwerk-FSs bin ich mit dem Vorhandensein einer Backend-Speicherebene, die über jedes lokale FS implementiert wird, nicht zufrieden. Die Existenz dieser Ebene ist völlig ungerechtfertigt. Der Netzwerk-FS muss direkt mit der Blockschicht interagieren und darf den lokalen FS nicht auffordern, andere Dienstdateien zu erstellen!
Im Allgemeinen ist die Aufteilung von Dateisystemen in lokale und Netzwerksysteme etwas Schlechtes. Es entstand aus der Unvollkommenheit der Algorithmen, die vor dreißig Jahren verwendet wurden und für deren Ersatz bisher nichts vorgeschlagen wurde. Dies ist auch der Grund für das Auftreten einer Vielzahl unnötiger Softwarekomponenten (verschiedene Dienste usw.). Im Idealfall sollte auf jedem Computer nur ein FS in Form eines Kernelmoduls und einer Reihe von Benutzerdienstprogrammen installiert sein – ein Clusterknoten. Dieser FS ist sowohl lokal als auch netzwerkfähig. Und nichts weiter!
Sollte mit Reiser4 unter Linux nichts klappen, würde ich gerne einen FS für FreeBSD anbieten (Zitat aus einem früheren Interview: „...FreeBSD... hat akademische Wurzeln... Und das bedeutet, dass wir mit hoher Wahrscheinlichkeit wird eine gemeinsame Sprache mit den Entwicklern finden“)?
Wie wir gerade herausgefunden haben, hat mit Linux bereits alles perfekt geklappt: Es gibt einen separaten funktionierenden Reiser4-Port dafür in Form eines Master-Zweigs unseres Repositorys. Ich habe FreeBSD nicht vergessen! Angebot! Ich bin bereit, eng mit denen zusammenzuarbeiten, die sich gut mit FreeBSD auskennen. Übrigens: Was mir an ihrer Community wirklich gefällt, ist, dass dort Entscheidungen von einem aktualisierten Rat unabhängiger Experten getroffen werden, was nichts mit der Täuschung einer festen Person durch die Regierung zu tun hat.
Wie bewerten Sie die Linux-Benutzergemeinschaft heute? Ist es „Pop“ geworden?
Angesichts der Art meiner Arbeit fällt es mir ziemlich schwer, dies zu beurteilen. Meistens kommen Benutzer mit Fehlerberichten und Anfragen zur Behebung des Abschnitts zu mir. Benutzer als Benutzer. Manche sind klüger, manche weniger. Alle werden gleich behandelt. Nun, wenn der Benutzer meine Anweisungen ignoriert, dann entschuldigen Sie: Der Ignorierbefehl wird auch von meiner Seite eingegeben.
Lässt sich die Entwicklung von Dateisystemen für die nächsten fünf bis zehn Jahre vorhersagen? Was sind Ihrer Meinung nach die größten Herausforderungen für FS-Entwickler?
Ja, es ist nicht schwer, eine solche Prognose zu erstellen. Es gab schon lange keine Entwicklung von Dateisystemen im Upstream. Es entsteht nur der Anschein eines solchen. Entwickler lokaler Dateisysteme stießen auf Probleme im Zusammenhang mit schlechtem Design. Hier muss ein Vorbehalt gemacht werden. Ich betrachte das sogenannte „Speichern“, „Lecken“ und Portieren von Code nicht als Entwicklung und Weiterentwicklung. Und ich klassifiziere das Missverständnis namens „Btrfs“ aus den bereits erläuterten Gründen nicht als Entwicklung.
Jeder Patch verschlimmert die Probleme nur. Also. und es gibt immer verschiedene Arten von „Evangelisten“, für die „alles funktioniert“. Im Grunde handelt es sich dabei um Schüler und Studenten, die Vorlesungen schwänzen. Stellen Sie sich vor: Bei ihm klappt es, beim Professor aber nicht. Was für ein Adrenalinstoß das ist! Aus meiner Sicht wird der größte Schaden durch die „Handwerker“ verursacht, die sich beeilten, die wunderbaren Funktionen von Btrfs mit Begeisterung auf alle möglichen Ebenen wie Systemd, Docker usw. zu „schrauben“. - das ähnelt schon Metastasen.
Versuchen wir nun, eine Prognose für fünf bis zehn Jahre zu erstellen. Was wir in Reiser4 machen werden, habe ich bereits kurz aufgelistet. Die größte Herausforderung für lokale FS-Entwickler aus dem Upstream wird darin bestehen (ja, das ist bereits geschehen), dass sie nicht in der Lage sind, für ein Gehalt einen anständigen Job zu machen. Ohne irgendwelche Ideen im Bereich der Datenspeicherung werden sie weiterhin versuchen, diese unglücklichen VFS, XFS und ext4 zu patchen. Vor diesem Hintergrund sieht die Situation mit VFS besonders komisch aus und erinnert an die hektische Modernisierung eines Restaurants, in dem es keine Köche gibt und auch keine Köche erwartet werden.
Jetzt sperrt der VFS-Code ohne Bedingungen mehrere Speicherseiten gleichzeitig und lädt den zugrunde liegenden FS ein, auf ihnen zu arbeiten. Dies wurde eingeführt, um die Leistung von Ext4 bei Löschvorgängen zu verbessern. Es ist jedoch leicht zu verstehen, dass eine solche gleichzeitige Sperrung mit erweiterten Transaktionsmodellen völlig inkompatibel ist. Das heißt, Sie können nicht einfach Unterstützung für ein intelligentes Dateisystem im Kernel hinzufügen. Ich weiß nicht, wie die Situation in anderen Bereichen von Linux ist, aber was Dateisysteme betrifft, ist es unwahrscheinlich, dass eine Entwicklung hier mit der von Torvalds in der Praxis verfolgten Politik vereinbar ist (akademische Projekte werden rausgeschmissen, und Betrüger, die Ich habe keine Ahnung, was ein B-Baum ist, es werden endlose Vertrauenskredite vergeben). Daher wurden die Weichen für einen langsamen Verfall gestellt. Natürlich werden sie mit aller Kraft versuchen, es als „Entwicklung“ darzustellen.
Darüber hinaus werden die „Verwalter“ von Dateisystemen, die erkennen, dass man mit „Speicher“ allein nicht viel verdienen kann, ein profitableres Geschäft versuchen. Dies sind in der Regel verteilte Dateisysteme und Virtualisierung. Vielleicht portieren sie das modische ZFS woanders hin, wo es es noch nicht gibt. Aber er ähnelt, wie alle FS aus dem Upstream, einem Neujahrsbaum: Wenn man oben noch ein paar andere Kleinigkeiten aufhängen kann, dann kommt man nicht tiefer. Ich gebe zu, dass es möglich ist, ein seriöses Unternehmenssystem auf Basis von ZFS aufzubauen, aber da wir jetzt über die Zukunft diskutieren, kann ich leider nur sagen, dass ZFS in dieser Hinsicht hoffnungslos ist: Mit ihren virtuellen Geräten haben die Jungs den Sauerstoff abgeschnitten für sich selbst und künftige Generationen zur Weiterentwicklung. ZFS gehört der Vergangenheit an. Und ext4 und XFS sind noch nicht einmal vorgestern.
Das sensationelle Konzept des „Linux-Dateisystems der nächsten Generation“ ist gesondert zu erwähnen. Dabei handelt es sich um ein rein politisches und marketingtechnisches Projekt, das sozusagen mit dem Ziel ins Leben gerufen wurde, „die Zukunft der Dateisysteme“ unter Linux hinter bestimmte Charaktere zu stecken. Fakt ist, dass Linux früher „nur zum Spaß“ da war. Aber jetzt ist es in erster Linie eine Geldmaschine. Sie werden auf alles mögliche gemacht. Es ist zum Beispiel sehr schwierig, ein gutes Softwareprodukt zu entwickeln, aber kluge „Entwickler“ haben längst erkannt, dass es überhaupt keinen Grund gibt, sich anzustrengen: Sie können erfolgreich nicht existierende Software verkaufen, die in aller Öffentlichkeit angekündigt und beworben wurde Veranstaltungen – Hauptsache, die Präsentationsfolien sollten mehr „Features“ enthalten.
Hierfür eignen sich Dateisysteme hervorragend, denn auf das Ergebnis kann man getrost zehn Jahre lang verhandeln. Nun, wenn sich später jemand über das Fehlen genau dieses Ergebnisses beschwert, dann versteht er einfach nichts von Dateisystemen! Das erinnert an eine Finanzpyramide: An der Spitze stehen die Abenteurer, die dieses Chaos angerichtet haben, und die wenigen, die „Glück“ hatten: Sie haben „Dividenden abgezogen“, d. h. erhielten Geld für die Entwicklung, bekamen einen gut bezahlten Job als Manager, „tauchten“ auf Konferenzen auf usw.
Als nächstes kommen diejenigen, die „Pech“ haben: Sie zählen Verluste, kümmern sich um die Folgen der Bereitstellung eines unbrauchbaren Softwareprodukts in der Produktion usw. Es gibt noch viel mehr davon. Nun, an der Basis der Pyramide gibt es eine riesige Masse von Entwicklern, die nutzlosen Code „zersägen“. Sie sind die größten Verlierer, denn verschwendete Zeit kann nicht zurückgegeben werden. Solche Pyramiden sind für Torvalds und seine Mitarbeiter äußerst vorteilhaft. Und je mehr dieser Pyramiden, desto besser für sie. Um solche Pyramiden zu ernähren, kann alles in den Kern aufgenommen werden. In der Öffentlichkeit behauptet man natürlich das Gegenteil. Aber ich urteile nicht nach Worten, sondern nach Taten.
„Die Zukunft der Dateisysteme unter Linux“ ist also eine weitere stark beworbene, aber kaum nutzbare Software. Nach Btrfs wird mit hoher Wahrscheinlichkeit Bcachefs an die Stelle einer solchen „Zukunft“ treten, was ein weiterer Versuch ist, die Linux-Blockschicht mit einem Dateisystem zu überqueren (ein schlechtes Beispiel ist ansteckend). Und was typisch ist: Es gibt die gleichen Probleme wie bei Btrfs. Ich habe das schon lange vermutet, und dann konnte ich irgendwie nicht widerstehen und habe mir den Code angeschaut – es stimmt!
Die Autoren von Bcachefs und Btrfs nutzten bei der Erstellung ihrer FS aktiv die Quellen anderer Leute und verstanden wenig über sie. Die Situation erinnert stark an das Kinderspiel „kaputtes Telefon“. Und ich kann mir ungefähr vorstellen, wie dieser Code in den Kernel eingebunden wird. Tatsächlich wird niemand die „Rechen“ sehen (jeder wird später darauf treten). Nach zahlreichen Streitereien über den Stil des Codes, Vorwürfen nicht vorhandener Verstöße usw. wird eine Schlussfolgerung über die „Loyalität“ des Autors gezogen, wie gut er mit anderen Entwicklern „interagiert“ und wie erfolgreich dies alles sein kann dann an Konzerne verkauft werden.
Das Endergebnis wird niemanden interessieren. Vor zwanzig Jahren hätte ich mich vielleicht dafür interessiert, aber jetzt stellt sich die Frage anders: Wird es möglich sein, das so zu fördern, dass bestimmte Leute in den nächsten zehn Jahren beschäftigt werden? Und leider ist es nicht üblich, sich über das Endergebnis zu wundern.
Generell würde ich dringend davon abraten, Ihr Dateisystem von Grund auf neu zu erfinden. Denn selbst erhebliche finanzielle Investitionen werden nicht ausreichen, um in zehn Jahren etwas Wettbewerbsfähiges zu bekommen. Natürlich spreche ich von ernsthaften Projekten und nicht von solchen, die dazu gedacht sind, in den Kernel „geschoben“ zu werden. Eine effektivere Möglichkeit, sich auszudrücken, besteht also darin, sich echten Entwicklungen wie uns anzuschließen. Das ist natürlich nicht einfach – aber das ist bei jedem Projekt auf hohem Niveau der Fall.
Zunächst müssen Sie das von mir angebotene Problem selbstständig lösen. Danach werde ich, überzeugt von der Ernsthaftigkeit Ihrer Absichten, mit der Hilfe beginnen. Traditionell nutzen wir ausschließlich eigene Entwicklungen. Ausnahmen bilden Komprimierungsalgorithmen und einige Hash-Funktionen. Wir schicken keine Entwickler auf Konferenzen und setzen uns dann auch nicht zusammen und kombinieren die Ideen anderer („vielleicht was wird passieren“), wie es bei den meisten Startups üblich ist.
Wir entwickeln alle Algorithmen selbst. Ich interessiere mich derzeit für die algebraischen und kombinatorischen Aspekte der Datenspeicherwissenschaft. Insbesondere endliche Körper, Asymptotik, Beweis von Ungleichungen. Es gibt auch Arbeit für normale Programmierer, aber ich muss Sie sofort warnen: Alle Vorschläge, „sich ein anderes FS anzusehen und dasselbe zu tun“, werden ignoriert. Dort werden auch Patches zur engeren Integration mit Linux über VFS landen.
Wir haben also keinen Rechenschaftsplan, aber wir haben ein Verständnis dafür, wohin wir uns bewegen müssen, und wir sind zuversichtlich, dass diese Richtung die richtige ist. Dieses Verständnis kam nicht in Form von Manna vom Himmel. Ich möchte Sie daran erinnern, dass wir über 29 Jahre Entwicklungserfahrung verfügen und zwei von Grund auf neu geschriebene Dateisysteme haben. Und die gleiche Anzahl an Dienstprogrammen zur Datenwiederherstellung. Und das ist eine Menge!
Source: opennet.ru