Visualização do Ext4

 (buredoranna.github.io)
6 pontos por GN⁺ 2024-01-09 | 1 comentários | Compartilhar no WhatsApp
  • Monta um arquivo preenchido com zeros como dispositivo de loop e compara antes e depois de mkfs.ext4, mostrando byte a byte quais estruturas o ext4 posiciona sobre o espaço vazio
  • O arquivo do experimento tem tamanho de 8 blocos, criado a partir de /dev/zero, e a imagem é organizada como blocos de 1024 bytes de largura por 64 bytes de altura, com cada pixel correspondendo a um byte
  • Como é difícil ler a estrutura do ext4 apenas pela saída de od, compara em imagens o estado preenchido com 0x00 e a distribuição de bytes após mkfs.ext4
  • Bytes com valor 0x00 podem parecer espaço vazio mesmo quando são dados pertencentes ao ext4, então só a visualização básica não consegue distinguir completamente a estrutura de propriedade
  • Depois de copiar um arquivo de 1024 bytes de /dev/urandom, procura o mesmo padrão e o marca com cores, permitindo verificar em conjunto os metadados do ext4 e a posição dos dados do usuário

Criando uma imagem ext4 sobre um arquivo vazio

  • É um experimento para verificar qual estrutura de bytes o ext4 adiciona ao executar mkfs.ext4 em uma unidade vazia preenchida apenas com 0x00
  • Manipular uma unidade ativa real, como /dev/sda, com dd é perigoso; portanto, em vez de uma unidade secundária em uma VM, usa-se um arquivo comum como dispositivo de loop
  • mount e umount conseguem lidar diretamente com um arquivo de loop sem losetup separado
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

Composição do arquivo de blocos experimental

  • O experimento sempre começa com um arquivo vazio criado por dd, usando /dev/zero como entrada
  • O tamanho do arquivo é calculado para que a imagem final apareça como 8 blocos
    • Cada bloco tem 1024 pixels/bytes de largura
    • 64 pixels/bytes de altura
  • O comando de criação é o seguinte
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • Logo após a criação, a saída de od está em um estado previsível, totalmente preenchida com 0x00
  • O tamanho da unidade usado é pequeno demais para incluir um journal, então a visualização com journal fica para um projeto futuro

Estrutura visível após mkfs.ext4

  • Depois de executar mkfs.ext4, vários valores aparecem dentro do arquivo que antes continha apenas 0x00, revelando a estrutura do sistema de arquivos criada pelo ext4
  • Porém, a saída de bytes de od é detalhada demais, dificultando entender a disposição geral
  • Ao convertê-la em uma imagem em que cada pixel representa um byte, é possível ver o arquivo de blocos de uma perspectiva mais ampla
  • A imagem do arquivo vazio mostra uma unidade inteira em 0x00, enquanto a imagem após mkfs.ext4 mostra onde os dados do ext4 foram colocados no disco

Como diferenciar dos dados do usuário

  • A imagem básica não distingue diretamente bytes do ext4 de bytes que não são do ext4
  • Mesmo que um byte seja um dado pertencente ao ext4, se seu valor for 0x00 ele é exibido com a mesma cor que outros bytes 0x00
  • Para distinguir os dados do ext4 dos dados do “usuário”, cria-se um arquivo de 1024 bytes a partir de /dev/urandom e ele é copiado para o dispositivo de loop montado
  • Ao ler o blockfile, o código de visualização verifica se os próximos 1024 bytes coincidem com os 1024 bytes do arquivo de referência
    • Se coincidirem, esses 1024 pixels são marcados com uma cor como dados do usuário
  • Com esse método, obtém-se uma imagem que mostra tanto a estrutura criada pelo ext4 quanto os dados do arquivo de usuário copiados

Animação e comparação com ext2

  • Depois das imagens estáticas, cria-se um GIF animado com base no mesmo método
  • Entre cada frame, o arquivo de dados do usuário é copiado três vezes para a unidade
    • Isso é mais expressivo do que fazer apenas um cp por frame
    • O tamanho do GIF também fica menor
  • Como comparação, também é fornecida uma animação semelhante para ext2

Links de referência

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-09
Comentários do Hacker News

  • Alguns anos atrás, no FOSDEM, fiz uma visualização gráfica real do ext4; o vídeo está aqui, e a visualização começa por volta dos 20 minutos
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    A parte da apresentação em que falo do trim do sistema de arquivos “azul” pode confundir: parece que o projetor do FOSDEM não conseguiu mostrar direito o azul-claro que eu estava usando. Na hora eu não percebi, e na tela do notebook estava normal. No blog também há um vídeo complementar em que as cores são renderizadas corretamente: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • Como muita gente tenta simplificar o uso de computadores, parece que estão desaparecendo aqueles elementos que naturalmente despertavam curiosidade e ensinavam aos poucos, mesmo sem ninguém tentar ensinar explicitamente
    Um exemplo é aquela pequena luz vermelha de atividade do disco rígido nos computadores antigos, que indicava quando o disco estava trabalhando. Quando ela piscava em certos padrões e vinha acompanhada daquele som satisfatório de leituras rápidas do disco, dava para saber que o jogo desta vez ia carregar de verdade. Parece um bom meio-termo manter escondida, mas ainda disponível, uma visão avançada para os curiosos; é bem possível que essas pessoas virem os nerds de computador da próxima geração e façam o mundo girar

    • Quando éramos crianças, pessoas mais velhas também provavelmente diziam: “É uma pena que os computadores de hoje não tenham LEDs mostrando o estado de cada bit dos registradores de controle, como nos mainframes. Simplificaram demais, deixaram burro. Nem dá para ver onde está o ponteiro de instruções, e isso é muito útil para ter uma noção do que o hardware realmente está fazendo”

  • Existe um utilitário chamado pixd que gera uma visualização de dados semelhante na linha de comando: https://github.com/FireyFly/pixd
    Porém, ele mostra apenas uma representação estática dos dados binários, e não é tão legal quanto o GIF animado do buredoranna, em que as mudanças no sistema de arquivos aparecem ao longo do tempo. Esse tipo de arranjo de pixels pode ser útil se for disposto sobre uma curva de Hilbert, em vez de desenhado linha por linha. Aprendi essa técnica com o plugin cantordust do Ghidra, e a 3blue1brown oferece uma intuição matemática sobre por que arranjos de pixels em curvas de Hilbert funcionam bem
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • Achei interessante a demonstração do nbdkit que visualiza E/S do sistema de arquivos: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • O autor dela também está nesta thread

  • Inspirado por este post, fiz 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
    O a.png resultante é reversível. Depois de convertê-lo de volta para um arquivo .ppm e pular os primeiros 15 bytes, deve sair um .ext4 válido

    • Se o Twitter não comprimisse, seria interessante armazenar arquivos grandes como imagens e usar o Twitter como um sistema de arquivos

  • Muito legal. Esse tipo de visualização de dados ajuda bastante a entender como um formato de disco realmente organiza os dados no disco, incluindo detalhes como pré-alocar metadados cuidadosamente para certos usos
    Eu queria ver o que acontece quando o espaço fica cheio, mas infelizmente a animação terminou antes desse ponto

  • Lembrei do innodb_ruby: https://github.com/jeremycole/innodb_ruby
    É um conjunto de ferramentas muito útil para visualizar e aprender a estrutura do InnoDB. Há um exemplo de uso aqui: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • Se o autor vir este comentário, converter o GIF em vídeo pode reduzir os bytes transferidos e permitir que os usuários usem controles de vídeo, como pausar, navegar e ajustar a velocidade
    Por exemplo, dá para converter com algo como ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4

  • Com o Kaitai IDE, é possível visualizar vários formatos binários byte a byte, e até bit a bit. Se minha memória não falha, também existe um arquivo de definição para ext4

  • Ao ver este diagrama, fiquei curioso se existe algum sistema de arquivos que permita armazenar metadados em um dispositivo separado
    Por exemplo, deixar os dados no HDD e os metadados em um SSD conectado. Ainda assim, metadados são muito mais fáceis de manter em cache na memória, então não acho que o ganho seja grande o suficiente para compensar a complexidade extra