6 poin oleh GN⁺ 2024-01-09 | 1 komentar | Bagikan ke WhatsApp
  • Dengan me-mount file yang diisi 0 sebagai perangkat loop dan membandingkan sebelum/sesudah mkfs.ext4, artikel ini menunjukkan pada tingkat byte struktur apa yang ditempatkan ext4 di atas ruang kosong
  • File eksperimen berukuran 8 blok yang dibuat dengan /dev/zero, dan citranya disusun seperti blok dengan lebar 1024 byte dan tinggi 64 byte sehingga satu piksel merepresentasikan satu byte
  • Karena sulit membaca struktur ext4 hanya dari output od, artikel ini membandingkan distribusi byte antara keadaan yang terisi 0x00 dan setelah mkfs.ext4 dalam bentuk gambar
  • Byte bernilai 0x00 dapat terlihat seperti ruang kosong meskipun merupakan data yang dimiliki ext4, sehingga dengan visualisasi dasar saja struktur yang dimiliki sulit dibedakan sepenuhnya
  • Setelah menyalin file /dev/urandom berukuran 1024 byte lalu mencari pola yang sama dan menandainya dengan warna, artikel ini juga memperlihatkan lokasi metadata ext4 dan data pengguna

Membuat image ext4 di atas file kosong

  • Ini adalah eksperimen untuk melihat struktur byte apa yang ditambahkan ext4 ketika mkfs.ext4 dijalankan pada drive kosong yang hanya terisi 0x00
  • Karena berbahaya menangani drive aktif seperti /dev/sda dengan dd, file biasa digunakan sebagai perangkat loop alih-alih drive tambahan di VM
  • mount dan umount dapat menangani file loop secara langsung tanpa losetup terpisah
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

Konfigurasi file blok untuk eksperimen

  • Eksperimen selalu dimulai dari file kosong yang dibuat dengan dd menggunakan /dev/zero sebagai input
  • Ukuran file dihitung agar image akhirnya terlihat sebagai 8 blok
    • Setiap blok memiliki lebar 1024 piksel/byte
    • Tinggi 64 piksel/byte
  • Perintah pembuatannya sebagai berikut
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • Tepat setelah dibuat, output od berada dalam kondisi yang dapat diprediksi karena seluruhnya terisi 0x00
  • Ukuran drive yang digunakan terlalu kecil untuk memuat jurnal, sehingga visualisasi dengan jurnal dibiarkan sebagai proyek berikutnya

Struktur yang terlihat setelah mkfs.ext4

  • Setelah mkfs.ext4 dijalankan, berbagai nilai muncul di dalam file yang tadinya hanya berisi 0x00, sehingga struktur filesystem yang dibuat ext4 menjadi terlihat
  • Namun, output byte dari od terlalu rinci untuk memahami tata letak keseluruhan
  • Jika diubah menjadi gambar dengan satu piksel mewakili satu byte, file blok dapat dilihat dari sudut pandang yang lebih luas
  • Image file kosong menunjukkan drive yang seluruhnya bernilai 0x00, sedangkan image setelah mkfs.ext4 menunjukkan di mana data ext4 ditempatkan pada disk

Cara membedakannya dari data pengguna

  • Image dasar tidak secara langsung membedakan byte ext4 dan byte non-ext4
  • Jika suatu byte merupakan data milik ext4 tetapi nilainya 0x00, byte itu akan ditampilkan dengan warna yang sama seperti byte 0x00 lainnya
  • Untuk membedakan data ext4 dan data “pengguna”, dibuat file /dev/urandom berukuran 1024 byte lalu disalin ke perangkat loop yang sudah di-mount
  • Kode visualisasi memeriksa saat membaca blockfile apakah 1024 byte berikutnya cocok dengan 1024 byte dari file referensi
    • Jika cocok, 1024 piksel tersebut diberi warna sebagai data pengguna
  • Dengan cara ini, diperoleh image yang memperlihatkan struktur buatan ext4 dan data file pengguna yang disalin secara bersamaan

Animasi dan perbandingan dengan ext2

  • Setelah image statis, dibuat animated GIF berdasarkan metode yang sama
  • Di antara setiap frame, file data pengguna disalin tiga kali ke drive
    • Lebih ekspresif daripada metode cp hanya sekali per frame
    • Ukuran GIF juga menjadi lebih kecil
  • Sebagai pembanding, animasi serupa untuk ext2 juga disediakan

Tautan referensi

1 komentar

 
GN⁺ 2024-01-09
Komentar Hacker News
  • Beberapa tahun lalu di FOSDEM pernah ada visualisasi grafis nyata ext4, videonya ada di sini dan visualisasinya mulai sekitar menit ke-20
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    Bagian dalam presentasi yang membahas trim filesystem "biru" mungkin membingungkan; sepertinya proyektor FOSDEM tidak bisa menampilkan biru muda yang saya pakai dengan benar. Saat presentasi saya tidak menyadarinya, dan di layar laptop terlihat baik-baik saja. Di blog juga ada video pendamping dengan warna yang dirender dengan benar: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • Karena banyak orang mencoba menyederhanakan penggunaan komputer, rasanya elemen-elemen yang secara alami memancing rasa ingin tahu dan sedikit demi sedikit mengajarkan sesuatu, tanpa harus sengaja diajarkan, jadi menghilang
    Contohnya perangkat kecil seperti lampu indikator hard disk merah pada komputer lama, yang memberi tahu bahwa disk sedang bekerja. Kalau lampunya berkedip dengan pola tertentu dan suara pembacaan disk yang cepat terdengar memuaskan, kita tahu game kali ini benar-benar akan termuat. Menyembunyikan tetapi tetap menyediakan tampilan lanjutan bagi orang-orang yang penasaran tampaknya kompromi yang bagus, dan besar kemungkinan orang-orang seperti itulah yang akan menjadi nerd komputer generasi berikutnya dan menjalankan dunia

    • Saat kita kecil pun, orang yang lebih tua mungkin berkata, “Sayang komputer zaman sekarang tidak punya LED yang menampilkan status tiap bit register kontrol seperti mainframe. Terlalu disederhanakan sampai bodoh. Kita bahkan tidak bisa melihat instruction pointer ada di mana, padahal itu sangat berguna untuk memahami apa yang sebenarnya dilakukan hardware”
  • Ada utilitas bernama pixd yang membuat visualisasi data serupa di command line: https://github.com/FireyFly/pixd
    Namun ini hanya menampilkan representasi statis dari data biner, dan tidak sekeren GIF animasi buredoranna yang memperlihatkan perubahan filesystem dari waktu ke waktu. Susunan piksel seperti ini bisa berguna jika ditempatkan di atas kurva Hilbert, bukan digambar baris demi baris. Saya mempelajari metode ini dari plugin Ghidra cantordust, dan 3blue1brown memberikan intuisi matematis tentang mengapa susunan piksel kurva Hilbert efektif
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • Demo nbdkit yang memvisualisasikan I/O filesystem menarik: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • Pembuatnya juga ada di thread ini
  • Terinspirasi oleh tulisan ini, saya mencoba eksperimen seperti ini
    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 yang dihasilkan bisa dikembalikan. Setelah dikonversi lagi menjadi file .ppm, lewati 15 byte pertama dan seharusnya akan keluar .ext4 yang valid

    • Kalau Twitter tidak melakukan kompresi, mungkin menarik juga menyimpan file besar sebagai gambar dan memakai Twitter seperti filesystem
  • Sangat keren. Visualisasi data seperti ini sangat membantu memahami bagaimana format disk benar-benar menata data di disk, misalnya detail seperti cara mengalokasikan metadata lebih dulu secara hati-hati untuk sebagian penggunaan
    Saya juga ingin melihat apa yang terjadi saat ruangnya penuh, tetapi sayangnya animasinya berakhir sebelum titik itu

  • Saya teringat innodb_ruby: https://github.com/jeremycole/innodb_ruby
    Ini adalah kumpulan alat yang sangat berguna untuk memvisualisasikan dan mempelajari struktur InnoDB. Contoh penggunaannya ada di sini: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • Jika penulis melihat komentar ini, mengonversi GIF menjadi video bisa mengurangi byte yang dikirim dan memungkinkan pengguna memakai kontrol video seperti jeda, seek, dan pengaturan kecepatan
    Misalnya bisa dikonversi seperti ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4

  • Dengan Kaitai IDE, berbagai format biner bisa divisualisasikan sampai tingkat byte, bahkan bit. Kalau ingatan saya benar, ada juga file definisi ext4

  • Melihat diagram ini membuat saya penasaran apakah ada filesystem yang bisa menyimpan metadata di perangkat terpisah
    Misalnya data ditempatkan di HDD dan metadata di SSD yang terhubung. Namun metadata jauh lebih mudah di-cache di memori, jadi rasanya manfaatnya tidak cukup besar untuk mengimbangi kompleksitas tambahan