Ext4の可視化

 (buredoranna.github.io)
6 ポイント 投稿者 GN⁺ 2024-01-09 | 1件のコメント | WhatsAppで共有
  • 0で埋めたファイルをループデバイスとしてマウントし、mkfs.ext4の実行前後を比較することで、ext4が空き領域上にどのような構造を配置するのかをバイト単位で示す
  • 実験用ファイルは/dev/zeroで作成した8ブロックサイズで、画像は幅1024バイト、高さ64バイトのブロックのように構成され、1ピクセルが1バイトに対応する
  • odの出力だけではext4の構造を読み取りにくいため、0x00で埋められた状態とmkfs.ext4実行後のバイト分布を画像で比較する
  • 値が0x00のバイトは、ext4が所有するデータであっても空き領域のように見えることがあるため、基本的な可視化だけでは所有構造を完全には区別しにくい
  • 1024バイトの/dev/urandomファイルをコピーした後、同じパターンを探して色で表示し、ext4メタデータとユーザーデータの位置をあわせて確認する

空ファイル上にext4イメージを作る

  • 0x00だけで埋められた空のドライブにmkfs.ext4を実行すると、ext4がどのようなバイト構造を追加するのかを確認する実験
  • 実際の/dev/sdaのような稼働中のドライブをddで扱う方法は危険なため、VMの補助ドライブの代わりに通常のファイルをループデバイスとして使用する
  • mountとumountは、別途losetupを使わずにloopファイルを直接扱える
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

実験用ブロックファイルの構成

  • 実験は常に/dev/zeroを入力とするddで作成した空ファイルから開始する
  • ファイルサイズは、最終画像が8ブロックに見えるように計算されている
    • 各ブロックは幅1024ピクセル/バイト
    • 高さ64ピクセル/バイト
  • 生成コマンドは次のとおり
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • 生成直後のod出力は、全体が0x00で埋められた予測可能な状態
  • 使用したドライブサイズはジャーナルを含めるには小さすぎるため、ジャーナルを含む可視化は今後のプロジェクトとして残されている

mkfs.ext4後に見える構造

  • mkfs.ext4実行後は、0x00だけだったファイル内にさまざまな値が現れ、ext4が作成したファイルシステム構造が見えてくる
  • ただしodのバイト出力は細かすぎて、全体の配置を把握しにくい
  • 1ピクセルが1バイトを表す画像に変換すると、ブロックファイルをより広い視点で見られる
  • 空ファイルの画像は全体が0x00のドライブを示し、mkfs.ext4後の画像はext4データがディスク上のどこに置かれたかを示す

ユーザーデータと区別する方法

  • 基本画像はext4のバイトと非ext4のバイトを直接区別しない
  • あるバイトがext4所有のデータであっても、値が0x00なら他の0x00バイトと同じ色で表示される
  • ext4データと「ユーザー」データを区別するため、1024バイトサイズの/dev/urandomファイルを作成し、マウント済みのループデバイスにコピーする
  • 可視化コードはblockfileを読み込む際、次の1024バイトが参照ファイルの1024バイトと一致するかを検査する
    • 一致した場合、その1024ピクセルをユーザーデータとして色付きで表示する
  • この方法により、ext4が作成した構造とコピーされたユーザーファイルデータが同時に見える画像を得られる

アニメーションとext2との比較

  • 静的画像の後には、同じ方法を基にanimated GIFを作成する
  • 各フレームの間で、ユーザーデータファイルをドライブに3回コピーする
    • フレームごとに1回だけcpする方式より表現力が高い
    • GIFサイズもより小さくなる
  • 比較対象として、ext2に対する同様のアニメーションもあわせて提供されている

参考リンク

関連記事

1件のコメント

 
GN⁺ 2024-01-09
Hacker News のコメント

  • 数年前の FOSDEM で ext4 の実際のグラフィカルな可視化を行った。動画はここにあり、可視化は20分あたりから始まる
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    発表中に「青色」のファイルシステム trim について話している部分は紛らわしいかもしれないが、FOSDEM のプロジェクターが私の使っていた薄い青を正しく表示できなかったようだ。発表時には気づかず、ノート PC の画面では問題なかった。ブログには色が正しくレンダリングされた付随動画もある: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • 多くの人が コンピューターの利用を単純化しようとするあまり、あえて教えようとしなくても自然に好奇心を刺激し、少しずつ理解させてくれていた要素が消えていっている気がする
    昔のコンピューターにあった赤いハードディスクアクセスランプのように、ディスクが動作中であることを知らせる小さな仕掛けがその例だ。特定のパターンで点滅し、高速なディスク読み取り音が気持ちよく続けば、今度こそゲームが本当にロードされるのだと分かった。好奇心の強い人たちが見られるように 詳細表示を隠しつつ残しておくくらいが良い妥協点に思えるし、そういう人たちが次世代のコンピューター nerd になって世の中を動かす可能性は高い

    • 私たちが子どもの頃にも、年配の人たちは「最近のコンピューターにはメインフレームのように 制御レジスター各ビットの状態を示す LED がなくて残念だ。あまりにも愚かに単純化されている。命令ポインターがどこにあるのかも見えないのに、ハードウェアが実際に何をしているのか感覚をつかむには本当に役立つのに」と言っていたのだろう

  • コマンドラインで似たようなデータ可視化を作ってくれる pixd というユーティリティがある: https://github.com/FireyFly/pixd
    ただしこれはバイナリデータの静的な表現を見せるだけで、ファイルシステムの変化が時間とともに現れる buredoranna のアニメーション GIF ほど格好よくはない。こうしたピクセル配列は、行単位で描くよりも ヒルベルト曲線上に配置すると有用な場合がある。この方法は Ghidra プラグイン cantordust で知り、3blue1brown がヒルベルト曲線によるピクセル配列が有効な理由について数学的な直感を与えてくれる
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • ファイルシステム I/O を可視化する nbdkit のデモが興味深かった: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • その作者もこのスレッドにいる

  • この記事に触発されて、こんな実験をしてみた
    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
    生成物である a.png は元に戻せる。再び .ppm ファイルに変換してから最初の15バイトを飛ばせば、有効な .ext4 が得られるはず

    • Twitter が圧縮しないのであれば、大きなファイルを画像として保存して Twitter をファイルシステムのように使うのも面白かっただろう

  • とても素晴らしい。こうしたデータ可視化は、ディスクフォーマットが実際にディスク上へデータをどう配置するのか、たとえば一部の用途のために メタデータを慎重に事前割り当てする方法といった細部を理解するのに大いに役立つ
    空間がいっぱいになったときにどうなるのかも見たかったが、残念ながらアニメーションはその時点の前に終わっていた

  • innodb_ruby を思い出した: https://github.com/jeremycole/innodb_ruby
    InnoDB の構造を可視化し、学ぶのに非常に便利なツール群だ。使用例はここにある: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • 作者がこのコメントを見るなら、GIF を動画に変換すれば転送バイト数を減らし、ユーザーが一時停止、シーク、速度調整といった 動画コントロールを使えるようになる
    たとえば ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4 のように変換すればよい

  • Kaitai IDE では、さまざまなバイナリ形式をバイト単位、さらにはビット単位まで可視化できる。記憶が正しければ ext4 の定義ファイルもある

  • この図を見ると、メタデータを別デバイスに保存できるファイルシステムがあるのか気になった
    たとえばデータは HDD に置き、メタデータは接続された SSD に置く方式だ。ただしメタデータはメモリにキャッシュするのがずっと簡単なので、追加の複雑さを相殺するほどの利点は大きくない気がする

    • ZFS では可能だ。ジャーナルを別デバイスに置ける別のファイルシステムも聞いたことがあるが、最近のウェブ検索はひどいので、どれだったか探し出す時間が足りなかった
    • この記事の special-vdev を見るとよい
      https://klarasystems.com/articles/openzfs-understanding-zfs-vdev-types/
    • Facebook はこのために XFS リアルタイムモードを悪用している。Omar がここで一部を扱っている: https://lwn.net/Articles/943693/
    • BcacheFS がこれを行う