Ext4 görselleştirmesi

 (buredoranna.github.io)
6 puan yazan GN⁺ 2024-01-09 | 1 yorum | WhatsApp'ta paylaş
  • mkfs.ext4 öncesi ve sonrasını karşılaştırmak için loop device olarak bağlanan, 0 ile doldurulmuş bir dosya kullanılıyor; böylece ext4’ün boş alan üzerine hangi yapıları yerleştirdiği bayt düzeyinde gösteriliyor
  • Deney dosyası /dev/zero ile oluşturulmuş 8 blok boyutunda; görüntü, genişliği 1024 bayt ve yüksekliği 64 bayt olan bloklar gibi düzenleniyor ve her piksel bir bayta karşılık geliyor
  • Yalnızca od çıktısıyla ext4 yapısını okumak zor olduğundan, 0x00 ile doldurulmuş durum ile mkfs.ext4 sonrası bayt dağılımı görüntü olarak karşılaştırılıyor
  • Değeri 0x00 olan baytlar, ext4’ün sahip olduğu veri olsa bile boş alan gibi görünebildiğinden, temel görselleştirme tek başına sahip olunan yapıları tamamen ayırt etmeyi zorlaştırıyor
  • 1024 baytlık bir /dev/urandom dosyası kopyalanıp aynı desen renklerle işaretlenerek, ext4 meta verileri ile kullanıcı verisinin konumu birlikte görülebiliyor

Boş bir dosya üzerinde ext4 imajı oluşturma

  • Bu, yalnızca 0x00 ile doldurulmuş boş bir sürücü üzerinde mkfs.ext4 çalıştırıldığında ext4’ün hangi bayt yapısını eklediğini inceleyen bir deney
  • Gerçek bir /dev/sda gibi canlı bir sürücüyü dd ile işlemek riskli olduğundan, VM’in ikincil sürücüsü yerine sıradan bir dosya loop device olarak kullanılıyor
  • mount ve umount, ayrı bir losetup olmadan loop dosyasını doğrudan işleyebiliyor
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

Deney için blok dosyasının yapısı

  • Deney her zaman girdi olarak /dev/zero kullanan dd ile oluşturulmuş boş bir dosyayla başlıyor
  • Dosya boyutu, nihai görüntü 8 blok olarak görünecek şekilde hesaplanıyor
    • Her blok 1024 piksel/bayt genişliğinde
    • 64 piksel/bayt yüksekliğinde
  • Oluşturma komutu şöyle
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • Oluşturmanın hemen ardından od çıktısı, tamamı 0x00 ile doldurulmuş öngörülebilir bir durumda
  • Kullanılan sürücü boyutu journal içermek için fazla küçük olduğundan, journal içeren görselleştirme daha sonraki bir projeye bırakılıyor

mkfs.ext4 sonrasında görülen yapı

  • mkfs.ext4 çalıştırıldıktan sonra, daha önce yalnızca 0x00 içeren dosyada çeşitli değerler ortaya çıkıyor ve ext4’ün oluşturduğu dosya sistemi yapısı görünür hale geliyor
  • Ancak od’nin bayt çıktısı, genel yerleşimi kavramak için fazla ayrıntılı
  • Her pikselin bir baytı temsil ettiği bir görüntüye dönüştürüldüğünde, blok dosyasına daha geniş bir perspektiften bakılabiliyor
  • Boş dosyanın görüntüsü tamamı 0x00 olan bir sürücüyü gösterirken, mkfs.ext4 sonrası görüntü ext4 verisinin diskte nereye yerleştirildiğini gösteriyor

Kullanıcı verisini ayırt etme yöntemi

  • Temel görüntü, ext4 baytları ile ext4 dışı baytları doğrudan ayırt etmiyor
  • Bir bayt ext4’ün sahip olduğu veri olsa bile değeri 0x00 ise, diğer 0x00 baytlarla aynı renkte gösteriliyor
  • ext4 verisi ile “kullanıcı” verisini ayırt etmek için 1024 bayt boyutunda bir /dev/urandom dosyası oluşturulup bağlanmış loop device’a kopyalanıyor
  • Görselleştirme kodu, blockfile okunurken sıradaki 1024 baytın başvuru dosyasındaki 1024 baytla eşleşip eşleşmediğini denetliyor
    • Eşleşirse ilgili 1024 piksel kullanıcı verisi olarak renkle işaretleniyor
  • Bu yöntemle, ext4’ün oluşturduğu yapılar ile kopyalanmış kullanıcı dosyası verisi aynı görüntüde görülebiliyor

Animasyon ve ext2 karşılaştırması

  • Statik görüntülerin ardından aynı yöntem temel alınarak bir animated GIF oluşturuluyor
  • Her kare arasında kullanıcı veri dosyası sürücüye üç kez kopyalanıyor
    • Her karede yalnızca bir kez cp kullanmaya göre daha ifade gücü yüksek
    • GIF boyutu da daha küçük oluyor
  • Karşılaştırma için ext2 üzerinde benzer bir animasyon da sunuluyor

Referans bağlantıları

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-09
Hacker News yorumları

  • Birkaç yıl önce FOSDEM'de ext4'ün gerçek bir grafiksel görselleştirmesini yaptım; video burada, görselleştirme de yaklaşık 20. dakikada başlıyor
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    Sunumda "mavi" dosya sistemi trim'inden bahsettiğim kısım kafa karıştırıcı olabilir; görünüşe göre FOSDEM projektörü kullandığım açık maviyi düzgün gösterememiş. Sunum sırasında fark etmedim, dizüstü ekranında gayet normal görünüyordu. Blogda renklerin doğru render edildiği eşlik eden bir video da var: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • Birçok kişi bilgisayar kullanımını basitleştirmeye çalıştıkça, özellikle öğretmeye gerek kalmadan doğal biçimde merak uyandıran ve azar azar bir şeyler öğreten unsurların ortadan kalktığını düşünüyorum
    Eski bilgisayarlardaki kırmızı sabit disk göstergesi gibi, diskin çalıştığını haber veren küçük bir parça buna örnek. Belli bir desende yanıp söndüğünde ve hızlı disk okuma sesi tatmin edici biçimde sürdüğünde, oyunun bu kez gerçekten yükleneceğini anlardınız. Meraklı insanların bakabilmesi için gelişmiş görünümü gizli de olsa bırakmak iyi bir uzlaşma gibi görünüyor; bu insanlar da muhtemelen bir sonraki neslin bilgisayar nerd'leri olup dünyayı döndürecek

    • Biz çocukken de yaşça büyük kişiler muhtemelen “Günümüz bilgisayarlarında mainframe'lerdeki gibi kontrol register'larının her bitinin durumunu gösteren LED'ler olmaması üzücü. Aşırı aptalca basitleştirildi. Komut işaretçisinin nerede olduğunu bile göremiyorsun; oysa donanımın gerçekte ne yaptığını sezmek için gerçekten çok faydalı” diyordu

  • Komut satırında benzer veri görselleştirmesi üreten pixd adlı bir yardımcı program var: https://github.com/FireyFly/pixd
    Ancak bu yalnızca ikili verinin statik bir temsilini gösteriyor; dosya sistemi değişikliklerinin zaman içinde göründüğü buredoranna'nın animasyonlu GIF'i kadar havalı değil. Böyle piksel dizilimlerini satır satır çizmek yerine Hilbert eğrisi üzerine yerleştirmek faydalı olabilir. Bu yöntemi Ghidra eklentisi cantordust'tan öğrendim; 3blue1brown da Hilbert eğrisi piksel dizilimlerinin neden etkili olduğuna dair matematiksel sezgiyi veriyor
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • Dosya sistemi G/Ç'sini görselleştiren nbdkit demosu ilginçti: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • Onun yazarı da bu başlıkta

  • Bu yazıdan ilham alıp şöyle bir deneme yaptım
    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
    Ortaya çıkan a.png geri döndürülebilir. Yeniden .ppm dosyasına dönüştürüp ilk 15 baytı atlarsanız geçerli bir .ext4 elde etmeniz gerekir

    • Twitter sıkıştırma yapmasaydı, büyük bir dosyayı görüntü olarak kaydedip Twitter'ı dosya sistemi gibi kullanmak da eğlenceli olabilirdi

  • Çok güzel. Bu tür veri görselleştirmeleri, disk formatının veriyi diskte gerçekte nasıl yerleştirdiğini; örneğin belli bir kullanım için metadata'yı dikkatle önceden ayırma gibi ayrıntıları anlamaya çok yardımcı oluyor
    Alan tamamen dolduğunda ne olduğunu da görmek isterdim, ama ne yazık ki animasyon o noktadan önce bitmiş

  • innodb_ruby aklıma geldi: https://github.com/jeremycole/innodb_ruby
    InnoDB yapısını görselleştirmek ve öğrenmek için çok kullanışlı bir araç seti. Kullanım örneği burada: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • Yazar bu yorumu görürse, GIF'i videoya dönüştürmek aktarılacak baytları azaltır ve kullanıcıların duraklatma, gezinme, hız ayarı gibi video kontrollerini kullanmasını sağlar
    Örneğin ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4 şeklinde dönüştürülebilir

  • Kaitai IDE ile birçok ikili formatı bayt düzeyinde, hatta bit düzeyine kadar görselleştirebilirsiniz. Yanlış hatırlamıyorsam ext4 tanım dosyası da var

  • Bu diyagramı görünce metadata'yı ayrı bir aygıtta saklayabilen dosya sistemleri var mı diye merak ettim
    Örneğin veriyi HDD'de, metadata'yı bağlı bir SSD'de tutmak gibi. Yine de metadata'yı bellekte cache'lemek çok daha kolay olduğundan, ek karmaşıklığı telafi edecek kadar büyük bir kazanç olmayabilir