Ext4 visualisieren

 (buredoranna.github.io)
6 Punkte von GN⁺ 2024-01-09 | 1 Kommentare | Auf WhatsApp teilen
  • Eine mit Nullen gefüllte Datei wird als Loop-Device eingebunden, um den Zustand vor und nach mkfs.ext4 zu vergleichen, und zeigt Byte für Byte, welche Strukturen ext4 auf leerem Speicherplatz anlegt
  • Die Testdatei hat die Größe von 8 Blöcken und wurde mit /dev/zero erstellt; das Bild ist als Block mit 1024 Byte Breite und 64 Byte Höhe aufgebaut, sodass ein Pixel genau einem Byte entspricht
  • Da sich die ext4-Struktur allein aus der od-Ausgabe nur schwer lesen lässt, wird die Byte-Verteilung des mit 0x00 gefüllten Zustands und des Zustands nach mkfs.ext4 als Bild verglichen
  • Bytes mit dem Wert 0x00 können auch dann wie freier Speicher aussehen, wenn sie zu ext4 gehören, sodass sich zugewiesene Strukturen mit der Grundvisualisierung nicht vollständig unterscheiden lassen
  • Nach dem Kopieren einer 1024-Byte-Datei aus /dev/urandom wird dasselbe Muster gesucht und farblich markiert, sodass sich ext4-Metadaten und die Position von Nutzerdaten gemeinsam prüfen lassen

Ein ext4-Image auf einer leeren Datei erzeugen

  • Dies ist ein Experiment, das zeigt, welche Byte-Struktur ext4 hinzufügt, wenn mkfs.ext4 auf einem leeren Laufwerk ausgeführt wird, das nur mit 0x00 gefüllt ist
  • Da es riskant wäre, mit dd auf einem Live-Laufwerk wie /dev/sda zu arbeiten, wird statt eines zusätzlichen VM-Laufwerks eine normale Datei als Loop-Device verwendet
  • mount und umount können eine Loop-Datei direkt auch ohne separates losetup verwenden
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

Aufbau der Blockdatei für das Experiment

  • Das Experiment beginnt immer mit einer leeren Datei, die mit dd unter Verwendung von /dev/zero als Eingabe erzeugt wird
  • Die Dateigröße wird so berechnet, dass das fertige Bild aus 8 Blöcken besteht
    • Jeder Block ist 1024 Pixel/Byte breit
    • 64 Pixel/Byte hoch
  • Der Erzeugungsbefehl lautet wie folgt
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • Direkt nach der Erzeugung zeigt die od-Ausgabe den erwartbaren Zustand, in dem alles mit 0x00 gefüllt ist
  • Das verwendete Laufwerk ist zu klein, um ein Journal aufzunehmen, daher bleibt eine Visualisierung mit Journal ein Projekt für später

Sichtbare Struktur nach mkfs.ext4

  • Nach der Ausführung von mkfs.ext4 erscheinen in der zuvor nur mit 0x00 gefüllten Datei verschiedene Werte, wodurch die von ext4 erzeugte Dateisystemstruktur sichtbar wird
  • Die Byte-Ausgabe von od ist jedoch zu detailliert, um das gesamte Layout gut zu erfassen
  • Wenn man sie in ein Bild umwandelt, in dem ein Pixel ein Byte darstellt, lässt sich die Blockdatei aus einer breiteren Perspektive betrachten
  • Das Bild der leeren Datei zeigt ein vollständig mit 0x00 gefülltes Laufwerk, und das Bild nach mkfs.ext4 zeigt, wo auf der Festplatte ext4-Daten abgelegt wurden

Abgrenzung zu Nutzerdaten

  • Das Grundbild unterscheidet ext4-Bytes und Nicht-ext4-Bytes nicht direkt
  • Wenn ein Byte zwar zu ext4-Daten gehört, aber den Wert 0x00 hat, wird es in derselben Farbe wie andere 0x00-Bytes dargestellt
  • Um ext4-Daten und „Nutzer“-Daten zu unterscheiden, wird eine 1024 Byte große Datei aus /dev/urandom erzeugt und auf das eingehängte Loop-Device kopiert
  • Der Visualisierungscode prüft beim Lesen der Blockdatei, ob die nächsten 1024 Byte mit den 1024 Byte der Referenzdatei übereinstimmen
    • Bei einer Übereinstimmung werden diese 1024 Pixel farblich als Nutzerdaten markiert
  • Auf diese Weise entsteht ein Bild, das sowohl die von ext4 erzeugten Strukturen als auch die kopierten Nutzerdaten der Datei zeigt

Animation und Vergleich mit ext2

  • Nach den statischen Bildern wird auf derselben Grundlage ein animiertes GIF erstellt
  • Zwischen jeweils zwei Frames wird die Nutzerdatendatei dreimal auf das Laufwerk kopiert
    • Das ist ausdrucksstärker, als pro Frame nur einmal cp auszuführen
    • Außerdem wird die GIF-Datei kleiner
  • Zum Vergleich wird auch eine ähnliche Animation für ext2 bereitgestellt

Weiterführende Links

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-09
Hacker-News-Kommentare

  • Vor einigen Jahren gab es auf der FOSDEM eine echte grafische Visualisierung von ext4; das Video ist hier, und die Visualisierung beginnt etwa ab Minute 20
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    Die Stelle im Vortrag, an der von einem „blauen“ Filesystem-Trim die Rede ist, kann verwirrend sein, aber offenbar konnte der FOSDEM-Projektor das helle Blau, das ich verwendet habe, nicht richtig darstellen. Während des Vortrags habe ich das nicht bemerkt, und auf dem Laptop-Bildschirm sah alles normal aus. Im Blog gibt es auch ein Begleitvideo mit korrekt gerenderten Farben: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • Weil so viele Menschen versuchen, die Nutzung von Computern zu vereinfachen, verschwinden anscheinend die Dinge, die ganz von selbst Neugier geweckt und einem nach und nach etwas beigebracht haben, ohne dass man sie ausdrücklich lehren musste
    Ein Beispiel dafür ist die rote Festplatten-LED früherer Computer, ein kleines Detail, das einem zeigte, dass die Platte gerade arbeitet. Wenn sie in einem bestimmten Muster blinkte und dazu das befriedigende Geräusch schneller Festplattenzugriffe zu hören war, wusste man, dass das Spiel diesmal wirklich geladen werden würde. Es scheint ein guter Kompromiss zu sein, eine erweiterte Ansicht zu verstecken, aber dennoch beizubehalten, damit neugierige Menschen sie entdecken können; genau solche Leute werden wahrscheinlich die nächste Generation von Computer-Nerds, die die Welt am Laufen halten

    • Als wir jung waren, haben ältere Leute vermutlich auch gesagt: „Schade, dass heutige Computer keine LEDs mehr haben, die wie bei Mainframes den Status jedes einzelnen Bits in den Steuerregistern anzeigen. Alles wurde zu stumpf vereinfacht. Man sieht nicht einmal, wo der Instruction Pointer steht, dabei ist das wirklich nützlich, um ein Gefühl dafür zu bekommen, was die Hardware tatsächlich tut.“

  • Es gibt ein Utility namens pixd, das in der Kommandozeile eine ähnliche Datenvisualisierung erzeugt: https://github.com/FireyFly/pixd
    Es zeigt allerdings nur eine statische Darstellung binärer Daten und ist nicht so beeindruckend wie das animierte GIF von buredoranna, in dem Veränderungen im Filesystem über die Zeit sichtbar werden. Solche Pixelanordnungen können nützlicher sein, wenn man sie statt zeilenweise entlang einer Hilbert-Kurve anordnet. Ich habe diese Methode durch das Ghidra-Plugin cantordust kennengelernt, und 3blue1brown liefert eine mathematische Intuition dafür, warum Pixelanordnungen auf Hilbert-Kurven so effektiv sind
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • Die nbdkit-Demo, die Filesystem-I/O visualisiert, war interessant: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • Deren Autor ist auch in diesem Thread

  • Durch diesen Beitrag angeregt habe ich folgendes Experiment ausprobiert
    dd if=/dev/zero bs=1K count=$(( 256 * 3 )) of=a.ext4
    mfks.ext4 a.ext4
    mkdir a
    sudo mount a.ext4 a
    cd a
    sudo chown 1000:1000 .
    python3 -c 'open("a", "wb").write(b"\xff\x00\x00" * 2000)'
    python3 -c 'open("b", "wb").write(b"\xff\xff\x00" * 2000)'
    python3 -c 'open("c", "wb").write(b"\xff\x00\xff" * 2000)'
    cd ..
    sudo umount a
    (echo -n 'P6\n512 512\n255\n' ; cat a.ext4 ) > a.ppm
    convert a.ppm a.png
    Das resultierende a.png ist reversibel. Wenn man es wieder in eine .ppm-Datei umwandelt und dann die ersten 15 Bytes überspringt, sollte wieder eine gültige .ext4 herauskommen

    • Wenn Twitter damals nicht komprimiert hätte, wäre es lustig gewesen, große Dateien als Bilder zu speichern und Twitter wie ein Filesystem zu benutzen

  • Sehr cool. Solche Datenvisualisierungen helfen enorm dabei zu verstehen, wie Disk-Formate Daten tatsächlich auf dem Datenträger anordnen, etwa Details wie die sorgfältige Vorabzuweisung von Metadaten für einen Teil der Nutzung
    Ich hätte auch gern gesehen, was passiert, wenn der Platz komplett voll ist, aber leider endet die Animation schon vorher

  • Das erinnerte mich an innodb_ruby: https://github.com/jeremycole/innodb_ruby
    Das ist eine sehr nützliche Werkzeugsammlung, um InnoDB-Strukturen zu visualisieren und zu verstehen. Ein Anwendungsbeispiel gibt es hier: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • Falls der Autor diesen Kommentar sieht: Wenn man das GIF in ein Video umwandelt, reduziert das die übertragenen Bytes, und Nutzer können Videosteuerungen wie Pause, Scrubbing und Geschwindigkeitsregelung verwenden
    Zum Beispiel kann man mit ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4 konvertieren

  • Mit Kaitai IDE kann man verschiedene Binärformate auf Byte-Ebene und sogar auf Bit-Ebene visualisieren. Wenn ich mich richtig erinnere, gibt es auch eine ext4-Definitionsdatei

  • Beim Ansehen dieses Diagramms habe ich mich gefragt, ob es Filesysteme gibt, die Metadaten auf einem separaten Gerät speichern können
    Zum Beispiel die Daten auf einer HDD und die Metadaten auf einer angeschlossenen SSD. Metadaten lassen sich allerdings viel leichter im Speicher cachen, daher ist der Vorteil vermutlich nicht groß genug, um die zusätzliche Komplexität aufzuwiegen