Visualisation d’Ext4

 (buredoranna.github.io)
6 points par GN⁺ 2024-01-09 | 1 commentaires | Partager sur WhatsApp
  • Monte un fichier rempli de zéros comme périphérique loop et compare l’avant/après mkfs.ext4 pour montrer, octet par octet, quelles structures ext4 place sur un espace vide
  • Le fichier d’expérimentation a une taille de 8 blocs créés avec /dev/zero, et l’image est organisée en blocs de 1024 octets de large sur 64 octets de haut, de sorte qu’un pixel corresponde à un octet
  • Comme la sortie de od seule rend la structure d’ext4 difficile à lire, il compare en image la distribution des octets entre l’état rempli de 0x00 et l’état après mkfs.ext4
  • Les octets valant 0x00 peuvent sembler être de l’espace vide même lorsqu’ils appartiennent à des données gérées par ext4, si bien qu’une visualisation de base ne permet pas de distinguer complètement les structures possédées
  • Après avoir copié un fichier de 1024 octets issu de /dev/urandom, il repère le même motif et l’affiche en couleur afin de visualiser à la fois les métadonnées ext4 et l’emplacement des données utilisateur

Créer une image ext4 sur un fichier vide

  • Il s’agit d’une expérience visant à voir quelle structure d’octets ext4 ajoute lorsqu’on exécute mkfs.ext4 sur un disque vide rempli uniquement de 0x00
  • Comme manipuler un disque actif comme /dev/sda avec dd est risqué, un fichier ordinaire est utilisé comme périphérique loop à la place d’un disque secondaire de VM
  • mount et umount peuvent manipuler directement un fichier loop sans losetup séparé
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

Configuration du fichier bloc pour l’expérience

  • L’expérience commence toujours avec un fichier vide créé par dd en utilisant /dev/zero comme entrée
  • La taille du fichier est calculée pour que l’image finale apparaisse comme 8 blocs
    • Chaque bloc fait 1024 pixels/octets de large
    • 64 pixels/octets de haut
  • La commande de création est la suivante
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • Juste après sa création, la sortie de od montre un état prévisible entièrement rempli de 0x00
  • La taille de disque utilisée est trop petite pour inclure un journal, donc la visualisation avec journal est laissée à un projet ultérieur

La structure visible après mkfs.ext4

  • Après l’exécution de mkfs.ext4, plusieurs valeurs apparaissent dans le fichier auparavant rempli uniquement de 0x00, ce qui révèle la structure du système de fichiers créée par ext4
  • Mais la sortie des octets de od est trop détaillée pour comprendre la disposition d’ensemble
  • En la transformant en image où chaque pixel représente un octet, on peut observer le fichier bloc avec une vue plus large
  • L’image du fichier vide montre un disque entièrement rempli de 0x00, et l’image après mkfs.ext4 montre où les données d’ext4 sont placées sur le disque

Comment les distinguer des données utilisateur

  • L’image de base ne distingue pas directement les octets d’ext4 des autres octets
  • Même si un octet appartient à des données gérées par ext4, s’il vaut 0x00 il sera affiché avec la même couleur que les autres octets à 0x00
  • Pour distinguer les données d’ext4 des données « utilisateur », un fichier de 1024 octets est créé à partir de /dev/urandom, puis copié sur le périphérique loop monté
  • Le code de visualisation vérifie, lors de la lecture du blockfile, si les 1024 octets suivants correspondent aux 1024 octets du fichier de référence
    • En cas de correspondance, les 1024 pixels concernés sont colorés comme données utilisateur
  • Cette méthode permet d’obtenir une image montrant à la fois les structures créées par ext4 et les données du fichier utilisateur copiées

Animation et comparaison avec ext2

  • Après les images statiques, un GIF animé est créé à partir de la même approche
  • Entre chaque image, le fichier de données utilisateur est copié trois fois sur le disque
    • C’est plus expressif qu’un simple cp une seule fois par image
    • La taille du GIF est aussi plus petite
  • Une animation similaire pour ext2 est également fournie à titre de comparaison

Liens de référence

À lire aussi

1 commentaires

 
GN⁺ 2024-01-09
Avis sur Hacker News

  • Il y a quelques années, à la FOSDEM, j’ai fait une vraie visualisation graphique d’ext4 ; la vidéo est ici, et la visualisation commence vers la 20e minute
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    Le passage de la présentation où je parle du trim du système de fichiers « bleu » peut prêter à confusion : il semble que le projecteur de la FOSDEM n’ait pas affiché correctement le bleu clair que j’utilisais. Je ne m’en suis pas rendu compte pendant la présentation, et tout avait l’air correct sur l’écran de mon portable. Il y a aussi sur le blog une vidéo d’accompagnement où les couleurs sont bien rendues : https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • À force de vouloir simplifier l’usage des ordinateurs, beaucoup d’éléments qui éveillaient naturellement la curiosité et apprenaient des choses petit à petit, sans qu’il soit nécessaire de les enseigner explicitement, semblent disparaître
    Un exemple : ces petits dispositifs qui indiquaient qu’un disque était en activité, comme le voyant rouge du disque dur sur les anciens ordinateurs. Quand il clignotait selon un certain motif et que le bruit satisfaisant d’une lecture rapide du disque suivait, on savait que le jeu allait vraiment se charger cette fois. Garder des vues avancées cachées, mais disponibles pour les curieux, semble être un bon compromis ; ce sont probablement eux qui deviendront la prochaine génération de nerds de l’informatique qui feront tourner le monde

    • Quand nous étions enfants, les plus âgés devaient déjà dire : « C’est dommage que les ordinateurs d’aujourd’hui n’aient plus de LED qui montrent l’état de chaque bit des registres de contrôle, comme sur les mainframes. Tout a été simplifié de façon trop bête. On ne voit même plus où se trouve le pointeur d’instruction, alors que c’est vraiment utile pour comprendre ce que fait réellement le matériel »

  • Il existe un utilitaire appelé pixd qui produit une visualisation de données similaire en ligne de commande : https://github.com/FireyFly/pixd
    Cela dit, il ne montre qu’une représentation statique des données binaires, et ce n’est pas aussi impressionnant que le GIF animé de buredoranna où l’on voit l’évolution du système de fichiers dans le temps. Ce type d’arrangement de pixels peut être utile lorsqu’il est placé le long d’une courbe de Hilbert, plutôt que tracé ligne par ligne. J’ai découvert cette méthode avec le plugin Ghidra cantordust, et 3blue1brown donne une intuition mathématique expliquant pourquoi les arrangements de pixels selon une courbe de Hilbert sont efficaces
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • La démo nbdkit visualisant les entrées/sorties d’un système de fichiers était intéressante : https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • Son auteur est aussi dans ce fil

  • Inspiré par cet article, j’ai tenté cette expérience
    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
    Le fichier a.png obtenu est réversible. Si on le reconvertit en fichier .ppm puis qu’on saute les 15 premiers octets, on devrait obtenir un .ext4 valide

    • Si Twitter ne compressait pas les images, il aurait été amusant de stocker un gros fichier sous forme d’image et d’utiliser Twitter comme système de fichiers

  • Très chouette. Ce genre de visualisation de données aide beaucoup à comprendre comment un format de disque dispose réellement les données sur le disque, par exemple des détails comme le fait de préallouer soigneusement des métadonnées pour une partie de l’utilisation
    J’aurais aussi voulu voir ce qui se passe quand l’espace est plein, mais malheureusement l’animation s’arrête avant ce moment

  • Ça m’a fait penser à innodb_ruby : https://github.com/jeremycole/innodb_ruby
    C’est une suite d’outils très utile pour visualiser et apprendre la structure d’InnoDB. Un exemple d’utilisation se trouve ici : https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • Si l’auteur voit ce commentaire, convertir le GIF en vidéo réduirait le volume d’octets à transférer et permettrait aux utilisateurs d’utiliser des contrôles vidéo comme la pause, la navigation dans la timeline et le réglage de la vitesse
    Par exemple, on peut le convertir avec ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4

  • Kaitai IDE permet de visualiser de nombreux formats binaires au niveau de l’octet, et même du bit. Si ma mémoire est bonne, il existe aussi un fichier de définition ext4

  • En voyant ce diagramme, je me demande s’il existe des systèmes de fichiers capables de stocker les métadonnées sur un périphérique séparé
    Par exemple, mettre les données sur un HDD et les métadonnées sur un SSD connecté. Cela dit, les métadonnées sont beaucoup plus faciles à mettre en cache en mémoire, donc le gain ne serait sans doute pas assez important pour compenser la complexité supplémentaire