Ext4 विज़ुअलाइज़ेशन

 (buredoranna.github.io)
6 पॉइंट द्वारा GN⁺ 2024-01-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 0 से भरी हुई फ़ाइल को loop device के रूप में mount करके mkfs.ext4 से पहले और बाद की स्थिति की तुलना की गई है, ताकि byte स्तर पर दिखाया जा सके कि ext4 खाली जगह पर कौन-सी संरचनाएँ रखता है
  • प्रयोग में इस्तेमाल की गई फ़ाइल /dev/zero से बनाई गई 8 ब्लॉक आकार की है, और इमेज को 1024-byte चौड़ाई तथा 64-byte ऊँचाई वाले ब्लॉकों के रूप में व्यवस्थित किया गया है, जहाँ एक pixel एक byte के बराबर है
  • सिर्फ od आउटपुट से ext4 की संरचना पढ़ना कठिन है, इसलिए 0x00 से भरी हुई स्थिति और mkfs.ext4 के बाद के byte वितरण की तुलना इमेज के रूप में की गई है
  • जिन bytes का मान 0x00 है, वे ext4 के स्वामित्व वाले डेटा होने पर भी खाली जगह जैसे दिख सकते हैं, इसलिए केवल मूल विज़ुअलाइज़ेशन से स्वामित्व वाली संरचनाओं को पूरी तरह अलग करना मुश्किल है
  • 1024-byte की /dev/urandom फ़ाइल कॉपी करने के बाद उसी pattern को खोजकर रंग से दिखाया गया है, ताकि ext4 metadata और user data की स्थिति दोनों को साथ देखा जा सके

खाली फ़ाइल पर ext4 इमेज बनाना

  • यह प्रयोग देखता है कि जब केवल 0x00 से भरी खाली drive पर mkfs.ext4 चलाया जाता है, तो ext4 कौन-सी byte संरचनाएँ जोड़ता है
  • असली /dev/sda जैसी live drive को dd से संभालना जोखिम भरा है, इसलिए VM की अतिरिक्त drive की जगह सामान्य फ़ाइल को loop device के रूप में इस्तेमाल किया गया है
  • mount और umount अलग losetup के बिना भी loop फ़ाइल को सीधे संभाल सकते हैं
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

प्रयोग के लिए ब्लॉक फ़ाइल की संरचना

  • प्रयोग हमेशा /dev/zero को input बनाकर dd से तैयार की गई खाली फ़ाइल से शुरू होता है
  • फ़ाइल का आकार इस तरह निकाला गया है कि अंतिम इमेज 8 ब्लॉक के रूप में दिखाई दे
    • हर ब्लॉक 1024 pixel/byte चौड़ा
    • 64 pixel/byte ऊँचा
  • बनाने का कमांड यह है
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • बनने के तुरंत बाद od आउटपुट पूरी तरह 0x00 से भरी हुई, अनुमानित स्थिति दिखाता है
  • इस्तेमाल की गई drive का आकार journal शामिल करने के लिए बहुत छोटा है, इसलिए journal सहित विज़ुअलाइज़ेशन को आगे के प्रोजेक्ट के लिए छोड़ा गया है

mkfs.ext4 के बाद दिखने वाली संरचना

  • mkfs.ext4 चलाने के बाद पहले केवल 0x00 वाली फ़ाइल में कई मान दिखाई देने लगते हैं, और ext4 द्वारा बनाई गई filesystem संरचना सामने आती है
  • लेकिन od का byte आउटपुट इतना सूक्ष्म है कि पूरी layout समझना कठिन हो जाता है
  • जब इसे ऐसी इमेज में बदला जाता है जहाँ एक pixel एक byte दिखाता है, तब block फ़ाइल को अधिक व्यापक नज़रिए से देखा जा सकता है
  • खाली फ़ाइल की इमेज पूरी तरह 0x00 वाली drive दिखाती है, और mkfs.ext4 के बाद की इमेज बताती है कि ext4 का डेटा डिस्क पर कहाँ रखा गया है

user data से अलग पहचानने का तरीका

  • मूल इमेज सीधे ext4 bytes और non-ext4 bytes में भेद नहीं करती
  • कोई byte ext4 के स्वामित्व वाले डेटा का हिस्सा हो, फिर भी यदि उसका मान 0x00 है, तो उसे दूसरे 0x00 bytes जैसा ही रंग दिया जाता है
  • ext4 डेटा और “user” डेटा को अलग करने के लिए 1024-byte आकार की /dev/urandom फ़ाइल बनाई जाती है और उसे mounted loop device पर कॉपी किया जाता है
  • blockfile पढ़ते समय विज़ुअलाइज़ेशन कोड जाँचता है कि अगले 1024 bytes संदर्भ फ़ाइल के 1024 bytes से मेल खाते हैं या नहीं
    • यदि मेल खाते हैं, तो उन 1024 pixels को user data के रूप में रंग से चिह्नित किया जाता है
  • इस तरीके से ext4 द्वारा बनाई गई संरचना और कॉपी किए गए user file data दोनों को साथ दिखाने वाली इमेज मिलती है

animation और ext2 तुलना

  • स्थिर इमेज के बाद, इसी तरीके के आधार पर animated GIF बनाया गया है
  • हर frame के बीच user data फ़ाइल को drive पर तीन बार कॉपी किया जाता है
    • हर frame में केवल एक बार cp करने की तुलना में यह अधिक प्रभावी प्रस्तुति देता है
    • GIF का आकार भी छोटा हो जाता है
  • तुलना के लिए ext2 का एक समान animation भी दिया गया है

संदर्भ लिंक

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-09
Hacker News की राय

  • कुछ साल पहले FOSDEM में ext4 का वास्तविक graphical visualization किया था, वीडियो यहां है और visualization करीब 20 मिनट के आसपास शुरू होता है
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    प्रेजेंटेशन में जहां "नीले" filesystem trim की बात है, वह थोड़ा भ्रमित कर सकता है; लगता है FOSDEM प्रोजेक्टर वह हल्का नीला रंग ठीक से नहीं दिखा पा रहा था जो मैं इस्तेमाल कर रहा था. प्रेजेंट करते समय मुझे पता नहीं चला और लैपटॉप स्क्रीन पर वह ठीक दिख रहा था. ब्लॉग पर रंग सही render हुए companion वीडियो भी है: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • बहुत से लोग computer इस्तेमाल को आसान बनाने की कोशिश करते हैं, और इस प्रक्रिया में लगता है कि वे चीजें गायब हो रही हैं जो बिना जानबूझकर सिखाए भी स्वाभाविक रूप से जिज्ञासा जगाती थीं और थोड़ा-थोड़ा सिखा देती थीं
    पुराने कंप्यूटरों की लाल hard disk indicator light की तरह—एक छोटी-सी चीज जो बताती थी कि disk काम कर रही है. अगर वह किसी खास pattern में blink करती और तेज disk-read की आवाज संतोषजनक ढंग से जारी रहती, तो पता चल जाता था कि game इस बार सच में load होने वाला है. जिज्ञासु लोगों के लिए advanced view को छिपाकर मगर मौजूद रखना एक अच्छा समझौता लगता है; और ऐसे ही लोग अगली पीढ़ी के computer nerd बनकर दुनिया चलाने की संभावना रखते हैं

    • जब हम बच्चे थे, तब भी बड़े लोग शायद कहते होंगे, “आजकल के computers में mainframe की तरह control register के हर bit की state दिखाने वाली LED नहीं होती, अफसोस. इसे बहुत बेवकूफी से simplified कर दिया गया है. instruction pointer कहां है यह भी नहीं देख सकते, जबकि hardware असल में क्या कर रहा है इसका अंदाजा लगाने में यह बेहद उपयोगी होता है”

  • command line पर मिलते-जुलते data visualization बनाने वाली pixd नाम की utility है: https://github.com/FireyFly/pixd
    हालांकि यह binary data का सिर्फ static representation दिखाती है, और buredoranna के animated GIF जितनी शानदार नहीं है, जिसमें filesystem changes समय के साथ दिखते हैं. ऐसे pixel arrays को line-by-line draw करने के बजाय Hilbert curve पर रखना उपयोगी हो सकता है. यह तरीका मैंने Ghidra plugin cantordust से सीखा, और 3blue1brown Hilbert curve pixel arrays के प्रभावी होने के पीछे की mathematical intuition देता है
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • filesystem I/O को visualize करने वाला nbdkit demo दिलचस्प था: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • उसके author भी इस thread में हैं

  • इस लेख से प्रेरित होकर यह experiment किया
    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 file में convert करने के बाद पहले 15 bytes skip करें, तो एक valid .ext4 मिलना चाहिए

    • अगर Twitter compression नहीं करता, तो बड़ी file को image के रूप में save करके Twitter को filesystem की तरह इस्तेमाल करना भी मजेदार होता

  • बेहद शानदार. इस तरह का data visualization यह समझने में बहुत मदद करता है कि disk format असल में disk पर data कैसे व्यवस्थित करता है—मसलन कुछ usage के लिए metadata को सावधानी से पहले से allocate करने जैसी details
    मैं यह भी देखना चाहता था कि space भर जाने पर क्या होता है, लेकिन अफसोस animation उससे पहले ही खत्म हो गया

  • innodb_ruby याद आया: https://github.com/jeremycole/innodb_ruby
    यह InnoDB structure को visualize करने और सीखने के लिए बहुत उपयोगी tools का set है. इस्तेमाल का example यहां है: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • अगर author यह comment देख रहे हों, तो GIF को video में बदलने से भेजे जाने वाले bytes कम होंगे और users pause, seek, speed control जैसे video controls इस्तेमाल कर पाएंगे
    उदाहरण के लिए ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4 की तरह convert किया जा सकता है

  • Kaitai IDE से कई binary formats को byte-level, यहां तक कि bit-level तक visualize किया जा सकता है. अगर मुझे सही याद है तो ext4 definition file भी है

  • यह diagram देखकर सोचने लगा कि क्या ऐसा कोई filesystem है जो metadata को अलग device पर store कर सकता हो
    उदाहरण के लिए data HDD पर रहे और metadata जुड़े हुए SSD पर. हालांकि metadata को memory में cache करना कहीं आसान होता है, इसलिए शायद extra complexity की भरपाई करने लायक फायदा बड़ा नहीं होगा

    • ZFS में यह संभव है. मैंने ऐसे दूसरे filesystems के बारे में भी सुना है जिनमें journal को अलग device पर रखा जा सकता है, लेकिन आजकल web search इतनी खराब है कि कौन सा था यह ढूंढने का समय नहीं मिला
    • इस लेख में special-vdev देखें
      https://klarasystems.com/articles/openzfs-understanding-zfs-vdev-types/
    • Facebook इसके लिए XFS real-time mode का दुरुपयोग करता है. Omar ने यहां इसका कुछ हिस्सा cover किया है: https://lwn.net/Articles/943693/
    • BcacheFS ऐसा करता है