Visualizing ext4

That’s… if I begin with a clean drive, a drive made fully of 0x00s, after which do mkfs.ext4, what does the drive, now embossed with ext4, appear like?
I imply, what I needed to see, is what it takes to transmogrify a bunch 0x00s, from “nothing” into the purposeful assemblage of bytes that’s an ext4 filesystem.
At first I figured I’d attempt visualizing a reside drive, like /dev/sda… however rapidly figured ‘dd’ + ‘reside drive’ may get me into hassle, so opted for including a small secondary drive to my VM.
Then I assumed, even with a digital machine, working with ‘dd’ and /dev/sdX can be extra hassle than it was price. I then remembered I didn’t have to make use of drives in any respect, digital or in any other case, I may simply work with a daily file, configured as a loop gadget.
And it seems mount/umount have advanced since I final experimented with loop units… you don’t must ‘losetup’ the loop gadget anymore only a easy:
# mount -o loop <foo_file> <bar_dir> # umount <bar_dir>
Is all that’s required
Utilizing a loop gadget simplified my efforts, and diminished the chance of a
dd accident.
So a little bit about what we’re taking a look at.
I all the time begin with a clean file… that could be a file created with ‘dd’ and a supply of ‘/dev/zero’… the calculated dimension of the file correspond to a last picture with eight blocks, every 64-pixels/bytes excessive, and 1024-pixels/bytes large.
$ dd if=/dev/zero of=blockfile.ext4 bs=$((64 * 1024)) depend=8
The output of that is predictable
$ od -x -A x blockfile.ext4 000000 0000 0000 0000 0000 0000 0000 0000 0000 * 080000
However I needed to see the distinction between a zero file, and one with no matter construction mkfs.ext4 provides to the drive…
Of word: the dimensions of drive I’m working with is just too small for a journal… however thats okay… Doing a visualization which features a journal I’m leaving for a future mission.
So now the output of ‘od’ of the blockfile which mkfs.ext4 is run in opposition to, is a bit more fascinating… right here we start to see construction:
$ od -x -Ax blockfile.ext4 000000 0000 0000 0000 0000 0000 0000 0000 0000 * 000400 0040 0000 0200 0000 0019 0000 01e2 0000 000410 0035 0000 0001 0000 0000 0000 0000 0000 000420 2000 0000 2000 0000 0040 0000 0000 0000 000430 c737 5e10 0000 ffff ef53 0001 0001 0000 000440 c737 5e10 0000 0000 0000 0000 0001 0000 000450 0000 0000 000b 0000 0080 0000 0038 0000 000460 02c2 0000 046b 0000 927f 9037 d060 5e4c 000470 1b83 287a 7389 0001 0000 0000 0000 0000 000480 0000 0000 0000 0000 0000 0000 0000 0000 * 0004c0 0000 0000 0000 0000 0000 0000 0000 0003 0004d0 0000 0000 0000 0000 0000 0000 0000 0000 0004e0 0000 0000 0000 0000 0000 0000 7da5 5d6c 0004f0 72c1 5b42 719d b2ee 63d5 d142 0001 0040 000500 000c 0000 0000 0000 c737 5e10 0000 0000 000510 0000 0000 0000 0000 0000 0000 0000 0000 * 000560 0001 0000 0000 0000 0000 0000 0000 0000 000570 0000 0000 0104 0000 0015 0000 0000 0000 000580 0000 0000 0000 0000 0000 0000 0000 0000 * 0007f0 0000 0000 0000 0000 0000 0000 7d3f 9ace 000800 0006 0000 0016 0000 0026 0000 01e2 0035 000810 0002 0004 0000 0000 c571 4e0a 0035 4797 000820 0000 0000 0000 0000 0000 0000 0000 0000 000830 0000 0000 0000 0000 96a2 c509 0000 0000 000840 0000 0000 0000 0000 0000 0000 0000 0000 * 001800 ffff 002f 1fe0 0000 0000 0000 0000 0000 001810 0000 0000 0000 0000 0000 0000 0000 0000 * 001830 0000 0000 0000 0000 0000 0000 0000 8000 001840 ffff ffff ffff ffff ffff ffff ffff ffff * 001c00 0002 0000 000c 0201 002e 0000 0002 0000 001c10 000c 0202 2e2e 0000 000b 0000 03dc 020a 001c20 6f6c 7473 662b 756f 646e 0000 0000 0000 001c30 0000 0000 0000 0000 0000 0000 0000 0000 * 001ff0 0000 0000 0000 0000 000c de00 e669 11f0 002000 000b 0000 000c 0201 002e 0000 0002 0000 002010 03e8 0202 2e2e 0000 0000 0000 0000 0000 002020 0000 0000 0000 0000 0000 0000 0000 0000 * 0023f0 0000 0000 0000 0000 000c de00 0f7a 7b5d 002400 0000 0000 03f4 0000 0000 0000 0000 0000 002410 0000 0000 0000 0000 0000 0000 0000 0000 * 0027f0 0000 0000 0000 0000 000c de00 3e04 8f88 002800 0000 0000 03f4 0000 0000 0000 0000 0000 002810 0000 0000 0000 0000 0000 0000 0000 0000 * 002bf0 0000 0000 0000 0000 000c de00 3e04 8f88 002c00 0000 0000 03f4 0000 0000 0000 0000 0000 002c10 0000 0000 0000 0000 0000 0000 0000 0000 * 002ff0 0000 0000 0000 0000 000c de00 3e04 8f88 003000 0000 0000 03f4 0000 0000 0000 0000 0000 003010 0000 0000 0000 0000 0000 0000 0000 0000 * 0033f0 0000 0000 0000 0000 000c de00 3e04 8f88 003400 0000 0000 03f4 0000 0000 0000 0000 0000 003410 0000 0000 0000 0000 0000 0000 0000 0000 * [... snip ...]
However on the byte density supplied by the output of ‘od’, attempting to visualise the ext4 construction is like attempting to visualise the construction of three deciduous forests by inspecting the leaves of a single tree… I needed an image which might let me “zoom out”, giving me a greater concept of what I used to be taking a look at…
So I got here up with this… every blue block is 1024 pixels large, and 64 pixels excessive… every pixel represents a single byte… Nothing a lot to see right here, besides a drive made solely of 0x00s.
It begins to get fascinating after creating the ext4 filesystem, and see this…
With this picture we are able to can see the construction added by mkfs.ext4, and the place on the drive the ext4 information is situated.
Its price noting this picture doesn’t really differentiate between “ext4 bytes” and “non-ext4 bytes”. That’s, there could possibly be bytes owned by ext4, but when they’re 0x00s they’re colour coded the identical as every other 0x00… However even with this limitation, the picture is fascinating.
However I nonetheless needed a picture which differentiated between ext4 information and “consumer” information. My resolution was to create a file 1024 bytes in dimension from /dev/urandom, and replica that file to the mounted loop gadget. Then, in my visualization code, when studying the blockfile, I check if “the following 1024 bytes to be learn” match “the 1024 bytes of the reference file”, and in the event that they match, colour code these 1024 pixels accordingly.
And with consumer information copied to the drive, we get this:
Which I discover very satisfying… However nonetheless, I needed an animation. So I constructed an animated GIF.
Between every body, the “consumer information” file is copied to the drive 3 times… so there are three copies written every body… This makes for a extra expressive animation and a smaller GIF than if every body was a single ‘cp’ of the file.
I hope you get pleasure from this as a lot as I do.
And by means of comparability, here’s a related animation, however with ext2
Right here begins the ext4 rabbit gap…
Wikipedia
ext4 wiki
Admin Guide
e2fsprogs
ext4 Data Structures and Algorithms