Visualización de Ext4

 (buredoranna.github.io)
6 puntos por GN⁺ 2024-01-09 | 1 comentarios | Compartir por WhatsApp
  • Monta un archivo rellenado con ceros como dispositivo de loop y compara el antes y el después de mkfs.ext4, mostrando a nivel de byte qué estructuras coloca ext4 sobre el espacio vacío
  • El archivo de prueba tiene un tamaño de 8 bloques creado con /dev/zero, y la imagen está compuesta como bloques de 1024 bytes de ancho y 64 bytes de alto, de modo que cada píxel corresponde a un byte
  • Como solo con la salida de od es difícil leer la estructura de ext4, compara en imágenes la distribución de bytes entre el estado rellenado con 0x00 y el estado posterior a mkfs.ext4
  • Los bytes con valor 0x00 pueden parecer espacio vacío aunque sean datos propiedad de ext4, por lo que con la visualización básica es difícil distinguir por completo las estructuras asignadas
  • Después de copiar un archivo de 1024 bytes de /dev/urandom, busca ese mismo patrón y lo marca con color para identificar juntos los metadatos de ext4 y la ubicación de los datos del usuario

Crear una imagen ext4 sobre un archivo vacío

  • Es un experimento para comprobar qué estructura de bytes agrega ext4 cuando se ejecuta mkfs.ext4 sobre una unidad vacía rellenada solo con 0x00
  • Como manipular una unidad en uso como /dev/sda con dd es peligroso, en vez de un disco secundario de una VM se usa un archivo común como dispositivo de loop
  • mount y umount pueden manejar directamente el archivo loop sin necesidad de losetup
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

Configuración del archivo de bloques para el experimento

  • El experimento siempre parte de un archivo vacío creado con dd usando /dev/zero como entrada
  • El tamaño del archivo se calcula para que la imagen final se vea como 8 bloques
    • Cada bloque tiene 1024 píxeles/bytes de ancho
    • 64 píxeles/bytes de alto
  • El comando de creación es el siguiente
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • Justo después de crearlo, la salida de od muestra un estado predecible completamente rellenado con 0x00
  • El tamaño de la unidad usada es demasiado pequeño para incluir journal, así que la visualización con journal queda como proyecto para después

Estructura visible después de mkfs.ext4

  • Tras ejecutar mkfs.ext4, en el archivo que antes solo tenía 0x00 aparecen varios valores, revelando la estructura del sistema de archivos creada por ext4
  • Pero la salida de bytes de od es demasiado detallada para entender la distribución completa
  • Si se convierte en una imagen donde cada píxel representa un byte, el archivo de bloques puede verse desde una perspectiva más amplia
  • La imagen del archivo vacío muestra una unidad completamente en 0x00, y la imagen posterior a mkfs.ext4 muestra dónde se colocan los datos de ext4 en el disco

Cómo distinguirlos de los datos del usuario

  • La imagen básica no distingue directamente entre bytes de ext4 y bytes ajenos a ext4
  • Aunque un byte pertenezca a datos de ext4, si su valor es 0x00 se mostrará con el mismo color que otros bytes 0x00
  • Para distinguir los datos de ext4 de los datos “del usuario”, se crea un archivo de 1024 bytes desde /dev/urandom y se copia al dispositivo de loop montado
  • Al leer el blockfile, el código de visualización comprueba si los siguientes 1024 bytes coinciden con los 1024 bytes del archivo de referencia
    • Si coinciden, esos 1024 píxeles se colorean como datos del usuario
  • Con este método se obtiene una imagen en la que aparecen juntas la estructura creada por ext4 y los datos del archivo de usuario copiado

Animación y comparación con ext2

  • Después de las imágenes estáticas, se crea un GIF animado basado en el mismo método
  • Entre cada frame, el archivo de datos del usuario se copia tres veces a la unidad
    • Tiene más fuerza visual que hacer cp solo una vez por frame
    • Además reduce el tamaño del GIF
  • También se ofrece como comparación una animación similar para ext2

Enlaces de referencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-09
Opiniones de Hacker News

  • Hace unos años hice una visualización gráfica real de ext4 en FOSDEM; el video está aquí y la visualización empieza alrededor del minuto 20:
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    La parte de la charla donde hablo del trim del sistema de archivos "azul" puede ser confusa: parece que el proyector de FOSDEM no mostraba bien el azul claro que yo estaba usando. No me di cuenta durante la presentación, y en la pantalla de mi laptop se veía bien. En el blog también hay un video complementario con los colores renderizados correctamente: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • Como mucha gente intenta simplificar el uso de las computadoras, parece que están desapareciendo elementos que despertaban la curiosidad de forma natural y enseñaban poco a poco, aunque nadie intentara enseñarlos explícitamente.
    Un ejemplo es ese pequeño indicador que mostraba que el disco estaba trabajando, como la luz roja del disco duro en las computadoras antiguas. Si parpadeaba con cierto patrón y venía acompañado de una satisfactoria secuencia de lecturas rápidas del disco, uno sabía que esta vez el juego sí iba a cargar de verdad. Me parece un buen compromiso dejar, aunque sea escondida, una vista avanzada para que la vean los curiosos; es muy probable que esas personas se conviertan en la próxima generación de nerds de la computación que muevan el mundo.

    • Cuando éramos chicos, la gente mayor seguramente decía: “Es una lástima que las computadoras de hoy no tengan LEDs que muestren el estado de cada bit de los registros de control, como en los mainframes. Las simplificaron de forma demasiado tonta. Ni siquiera se puede ver dónde está el puntero de instrucción, y eso era realmente útil para hacerse una idea de qué está haciendo el hardware en realidad”.

  • Hay una utilidad llamada pixd que genera una visualización de datos similar desde la línea de comandos: https://github.com/FireyFly/pixd
    Sin embargo, solo muestra una representación estática de datos binarios, y no es tan vistosa como el GIF animado de buredoranna, donde los cambios del sistema de archivos aparecen con el tiempo. Este tipo de arreglos de píxeles puede ser útil si se coloca sobre una curva de Hilbert en lugar de dibujarlo línea por línea. Aprendí este método del plugin cantordust de Ghidra, y 3blue1brown ofrece una intuición matemática de por qué los arreglos de píxeles con curvas de Hilbert funcionan bien.
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • Me pareció interesante la demo de nbdkit para visualizar la E/S del sistema de archivos: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • El autor de eso también está en este hilo.

  • Inspirado por este artículo, probé este experimento:
    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
    El resultado, a.png, es reversible. Si se convierte de nuevo a un archivo .ppm y se saltan los primeros 15 bytes, debería salir un .ext4 válido.

    • Si Twitter no comprimiera, habría sido divertido guardar archivos grandes como imágenes y usar Twitter como sistema de archivos.

  • Muy bueno. Este tipo de visualización de datos ayuda muchísimo a entender detalles de cómo un formato de disco realmente distribuye los datos en el disco, por ejemplo cómo preasigna cuidadosamente metadatos para cierto uso.
    Me habría gustado ver qué pasa cuando se llena todo el espacio, pero lamentablemente la animación termina antes de ese punto.

  • Me recordó a innodb_ruby: https://github.com/jeremycole/innodb_ruby
    Es un conjunto de herramientas muy útil para visualizar y aprender la estructura de InnoDB. Aquí hay un ejemplo de uso: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • Si el autor ve este comentario: convertir el GIF a video reduciría los bytes transferidos y permitiría a los usuarios usar controles de video como pausar, buscar y ajustar la velocidad.
    Por ejemplo, se puede convertir con algo como ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4.

  • Con Kaitai IDE se pueden visualizar varios formatos binarios a nivel de bytes, e incluso de bits. Si no recuerdo mal, también hay un archivo de definición para ext4.

  • Al ver este diagrama, me pregunto si hay sistemas de archivos que permitan guardar los metadatos en un dispositivo separado.
    Por ejemplo, dejando los datos en un HDD y los metadatos en un SSD conectado. Dicho eso, los metadatos son mucho más fáciles de cachear en memoria, así que no creo que el beneficio alcance para compensar la complejidad adicional.