Trực quan hóa Ext4

 (buredoranna.github.io)
6 điểm bởi GN⁺ 2024-01-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Gắn một tệp được điền bằng 0 làm thiết bị loop rồi so sánh trước và sau mkfs.ext4, qua đó cho thấy ext4 đặt những cấu trúc nào lên vùng trống ở mức từng byte
  • Tệp dùng cho thí nghiệm có kích thước 8 khối được tạo bằng /dev/zero, và ảnh được bố trí như các khối rộng 1024 byte và cao 64 byte để mỗi pixel tương ứng với một byte
  • Chỉ với đầu ra od thì khó đọc được cấu trúc ext4, nên bài viết so sánh phân bố byte giữa trạng thái được điền bằng 0x00 và sau mkfs.ext4 bằng hình ảnh
  • Các byte có giá trị 0x00 có thể trông như vùng trống dù đó là dữ liệu do ext4 sở hữu, nên chỉ với cách trực quan hóa cơ bản thì khó phân biệt hoàn toàn các cấu trúc được sở hữu
  • Sau khi sao chép một tệp /dev/urandom 1024 byte rồi tìm cùng mẫu đó và tô màu, có thể xác định đồng thời siêu dữ liệu ext4 và vị trí dữ liệu người dùng

Tạo ảnh ext4 trên tệp trống

  • Đây là thí nghiệm kiểm tra ext4 sẽ thêm những cấu trúc byte nào khi chạy mkfs.ext4 trên một ổ đĩa trống chỉ được điền bằng 0x00
  • Vì cách dùng dd với ổ đĩa thật như /dev/sda là nguy hiểm, nên thay vì dùng ổ phụ của VM, một tệp thông thường được dùng làm thiết bị loop
  • mount và umount có thể xử lý trực tiếp tệp loop mà không cần losetup riêng
    • mount -o loop <foo_file> <bar_dir>
    • umount <bar_dir>

Cấu hình tệp khối dùng cho thí nghiệm

  • Thí nghiệm luôn bắt đầu từ một tệp trống được tạo bằng dd với đầu vào là /dev/zero
  • Kích thước tệp được tính để ảnh cuối cùng hiển thị thành 8 khối
    • Mỗi khối rộng 1024 pixel/byte
    • Cao 64 pixel/byte
  • Lệnh tạo như sau
    • dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) count=8
  • Ngay sau khi tạo, đầu ra od ở trạng thái dễ dự đoán khi toàn bộ đều được điền bằng 0x00
  • Kích thước ổ đĩa được dùng quá nhỏ để chứa journal, nên phần trực quan hóa có journal được để lại cho một dự án sau

Cấu trúc xuất hiện sau mkfs.ext4

  • Sau khi chạy mkfs.ext4, trong tệp vốn chỉ có 0x00 bắt đầu xuất hiện nhiều giá trị khác nhau, làm lộ ra cấu trúc hệ thống tệp do ext4 tạo ra
  • Tuy nhiên, đầu ra byte của od quá chi tiết nên khó nắm được cách bố trí tổng thể
  • Khi chuyển thành ảnh mà mỗi pixel biểu diễn một byte, có thể quan sát tệp khối từ góc nhìn rộng hơn
  • Ảnh của tệp trống cho thấy một ổ đĩa toàn 0x00, còn ảnh sau mkfs.ext4 cho thấy dữ liệu ext4 nằm ở đâu trên đĩa

Cách phân biệt với dữ liệu người dùng

  • Ảnh cơ bản không trực tiếp phân biệt byte ext4 với các byte không phải ext4
  • Dù một byte là dữ liệu do ext4 sở hữu, nếu giá trị của nó là 0x00 thì nó vẫn sẽ được hiển thị cùng màu với các byte 0x00 khác
  • Để phân biệt dữ liệu ext4 với dữ liệu “người dùng”, một tệp /dev/urandom kích thước 1024 byte được tạo ra rồi sao chép vào thiết bị loop đã gắn
  • Khi đọc blockfile, mã trực quan hóa sẽ kiểm tra xem 1024 byte tiếp theo có khớp với 1024 byte của tệp tham chiếu hay không
    • Nếu khớp, 1024 pixel tương ứng sẽ được tô màu là dữ liệu người dùng
  • Bằng cách này có thể thu được hình ảnh hiển thị đồng thời các cấu trúc do ext4 tạo ra và dữ liệu tệp người dùng đã được sao chép

Hoạt ảnh và so sánh với ext2

  • Sau ảnh tĩnh, tác giả tiếp tục tạo một GIF động dựa trên cùng phương pháp
  • Giữa mỗi khung hình, tệp dữ liệu người dùng được sao chép ba lần vào ổ đĩa
    • Cách này biểu đạt tốt hơn so với việc chỉ cp một lần ở mỗi khung hình
    • Kích thước GIF cũng nhỏ hơn
  • Một hoạt ảnh tương tự cho ext2 cũng được cung cấp để so sánh

Liên kết tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-09
Ý kiến trên Hacker News

  • Vài năm trước tại FOSDEM đã có một bản trực quan hóa đồ họa thực tế của ext4, video ở đây và phần trực quan hóa bắt đầu khoảng phút thứ 20
    https://archive.fosdem.org/2019/schedule/event/nbdkit/
    Phần trong bài nói về trim của hệ thống tệp "màu xanh" có thể gây nhầm lẫn, vì có vẻ máy chiếu ở FOSDEM đã không hiển thị đúng màu xanh nhạt mà tôi dùng. Lúc thuyết trình tôi không nhận ra, còn trên màn hình laptop thì vẫn bình thường. Trên blog cũng có video đi kèm với màu được render chính xác: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

  • Nhiều người cố gắng đơn giản hóa việc dùng máy tính đến mức có cảm giác những yếu tố từng tự nhiên khơi gợi sự tò mò và giúp người dùng học thêm từng chút một, ngay cả khi không cố tình dạy họ, đang dần biến mất
    Một ví dụ là đèn báo ổ cứng màu đỏ trên các máy tính đời cũ, thứ cho bạn biết đĩa đang hoạt động. Khi nó nhấp nháy theo một kiểu nhất định và đi kèm tiếng đọc đĩa nhanh đầy thỏa mãn, bạn biết lần này game có lẽ sẽ thực sự tải xong. Có lẽ một thỏa hiệp tốt là vẫn giữ chế độ xem nâng cao nhưng ẩn nó đi để những người tò mò có thể tìm thấy; những người đó rất có thể sẽ trở thành thế hệ nerd máy tính tiếp theo vận hành thế giới này

    • Khi chúng ta còn nhỏ, có lẽ những người lớn tuổi hơn cũng từng nói kiểu như: “Máy tính bây giờ thật tiếc là không còn LED hiển thị trạng thái từng bit của thanh ghi điều khiển như trên mainframe. Nó bị đơn giản hóa đến mức ngớ ngẩn. Thậm chí còn không thấy được con trỏ lệnh đang ở đâu, trong khi thứ đó rất hữu ích để hình dung phần cứng thực sự đang làm gì”

  • Có một tiện ích tên pixd tạo ra kiểu trực quan hóa dữ liệu tương tự trên dòng lệnh: https://github.com/FireyFly/pixd
    Tuy nhiên nó chỉ hiển thị biểu diễn tĩnh của dữ liệu nhị phân, không ấn tượng bằng ảnh GIF động của buredoranna thể hiện các thay đổi của hệ thống tệp theo thời gian. Với kiểu mảng pixel này, có lẽ sẽ hữu ích hơn nếu sắp chúng theo đường cong Hilbert thay vì vẽ theo từng dòng. Tôi biết cách này từ plugin Ghidra là cantordust, và 3blue1brown có đưa ra trực giác toán học giải thích vì sao việc sắp pixel theo đường cong Hilbert lại hiệu quả
    https://inside.battelle.org/blog-details/battelle-publishes-open-source-binary-visualization-tool
    https://www.youtube.com/watch?v=3s7h2MHQtxc&t=311s

  • Bản demo nbdkit trực quan hóa I/O hệ thống tệp khá thú vị: https://rwmj.wordpress.com/2018/11/04/nbd-graphical-viewer/

    • Chính tác giả đó cũng có mặt trong thread này

  • Bài này khiến tôi thử một thí nghiệm như sau
    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
    Kết quả là a.png có thể đảo ngược lại. Chỉ cần chuyển nó về lại tệp .ppm, rồi bỏ qua 15 byte đầu tiên là sẽ thu được một tệp .ext4 hợp lệ

    • Nếu Twitter không nén ảnh, có lẽ sẽ thú vị khi lưu các tệp lớn thành hình ảnh và dùng Twitter như một hệ thống tệp

  • Rất tuyệt. Kiểu trực quan hóa dữ liệu này giúp ích rất nhiều trong việc hiểu các định dạng đĩa thực sự bố trí dữ liệu trên đĩa như thế nào, chẳng hạn những chi tiết như cách cấp phát trước metadata một cách cẩn thận cho một mức sử dụng nào đó
    Tôi cũng muốn xem chuyện gì xảy ra khi không gian bị lấp đầy hoàn toàn, nhưng tiếc là ảnh động kết thúc trước thời điểm đó

  • Nó làm tôi nhớ đến innodb_ruby: https://github.com/jeremycole/innodb_ruby
    Đây là một bộ công cụ rất hữu ích để trực quan hóa và tìm hiểu cấu trúc InnoDB. Có ví dụ sử dụng tại đây: https://blog.jcole.us/2014/10/02/visualizing-the-impact-of-ordered-vs-random-index-insertion-in-innodb/

  • Nếu tác giả có đọc bình luận này, việc chuyển GIF sang video có thể giảm số byte truyền đi và cho phép người dùng dùng các điều khiển video như tạm dừng, tua và chỉnh tốc độ
    Ví dụ có thể chuyển bằng cách như ffmpeg -i ext4.gif -pix_fmt yuv420p -c:v libx264 ext4.mp4

  • Có thể dùng Kaitai IDE để trực quan hóa nhiều định dạng nhị phân ở mức byte, thậm chí đến cả mức bit. Nếu tôi nhớ không nhầm thì cũng có tệp định nghĩa ext4

  • Sơ đồ này khiến tôi tự hỏi liệu có hệ thống tệp nào lưu metadata trên một thiết bị riêng hay không
    Ví dụ dữ liệu nằm trên HDD còn metadata nằm trên SSD gắn kèm. Tuy vậy metadata dễ được cache trong bộ nhớ hơn nhiều, nên có lẽ lợi ích không lớn đến mức bù lại được độ phức tạp tăng thêm

    • ZFS làm được điều này. Tôi cũng từng nghe về vài hệ thống tệp khác có thể đặt journal trên thiết bị riêng, nhưng tìm kiếm web dạo này quá tệ nên tôi không có thời gian tra ra đó là cái nào
    • Hãy xem phần special-vdev trong bài này
      https://klarasystems.com/articles/openzfs-understanding-zfs-vdev-types/
    • Facebook lạm dụng XFS real-time mode cho mục đích này. Omar có nói đến một phần ở đây: https://lwn.net/Articles/943693/
    • BcacheFS cũng làm vậy