- 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 setelahmkfs.ext4dalam 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/urandomberukuran 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.ext4dijalankan pada drive kosong yang hanya terisi 0x00 - Karena berbahaya menangani drive aktif seperti
/dev/sdadengandd, file biasa digunakan sebagai perangkat loop alih-alih drive tambahan di VM mountdanumountdapat menangani file loop secara langsung tanpalosetupterpisahmount -o loop <foo_file> <bar_dir>umount <bar_dir>
Konfigurasi file blok untuk eksperimen
- Eksperimen selalu dimulai dari file kosong yang dibuat dengan
ddmenggunakan/dev/zerosebagai 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
odberada 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.ext4dijalankan, berbagai nilai muncul di dalam file yang tadinya hanya berisi 0x00, sehingga struktur filesystem yang dibuat ext4 menjadi terlihat - Namun, output byte dari
odterlalu 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.ext4menunjukkan 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/urandomberukuran 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
cphanya sekali per frame - Ukuran GIF juga menjadi lebih kecil
- Lebih ekspresif daripada metode
- Sebagai pembanding, animasi serupa untuk ext2 juga disediakan
Tautan referensi
- Wikipedia: gambaran umum ext4
- ext4 wiki: wiki ext4
- Admin Guide: panduan admin ext4 kernel
- e2fsprogs: alat filesystem ext
- ext4 Data Structures and Algorithms: dokumentasi struktur data dan algoritme ext4
1 komentar
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
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/
Terinspirasi oleh tulisan ini, saya mencoba eksperimen seperti ini
dd if=/dev/zero bs=1K count=$(( 256 * 3 )) of=a.ext4mfks.ext4 a.ext4mkdir asudo mount a.ext4 acd asudo 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.ppmconvert a.ppm a.pnga.png yang dihasilkan bisa dikembalikan. Setelah dikonversi lagi menjadi file
.ppm, lewati 15 byte pertama dan seharusnya akan keluar.ext4yang validSangat 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
Duduk di depan komputer dan menonton program defrag Windows 95/98 lama berjalan adalah kenangan masa kecil yang menyenangkan: https://academy.avast.com/hs-fs/hubfs/New_Avast_Academy/how_to_defrag_your_pc_hard_drive_academy_refresh/img-06.png?width=600&name=img-06.png
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.mp4Dengan 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
https://klarasystems.com/articles/openzfs-understanding-zfs-vdev-types/