Visual walkthrough — ext4 structure — superblock, block groups, inodes

We build everything from zero. If you have never seen a bit, a byte, or a floor bracket, start at Step 1 and do not skip.

---

Step 1 — A disk is a flat array of blocks

WHAT. Picture the whole disk as one long row of identical boxes. Each box is a block — a fixed chunk of storage, commonly $4096$ bytes (that is $4$ KiB). We number them $0,1,2,\dots ,N-1$.

WHY. The hardware gives us no meaning — no "files", no "free space", just numbered boxes. Every clever thing ext4 does is a way of writing notes about these boxes into some of the boxes themselves. So the first picture is just the naked row.

PICTURE. Look at the row below. The label under a box is its block number. Nothing yet says which boxes are used — that is the very problem we must solve.

---

Step 2 — The question: "which boxes are free?"

WHAT. Before ext4 can store a file, it must know which blocks are already taken. We need a compact yes/no answer for every block: used ($1$) or free ($0$).

WHY a bitmap, not a list? We could keep a list of free block numbers, but a list of numbers is bulky and slow to search. Instead we use a bitmap: one bit per block. Bit $i$ answers one tiny question — "is block $i$ used?" This is the cheapest possible per-block record: exactly one switch each. (See Bitmaps for allocation for the general technique.)

PICTURE. Below, each block from Step 1 gets a bit sitting on top of it. A magenta bit ($1$) = used, a pale bit ($0$) = free. The strip of bits is the bitmap.

---

Step 3 — Where do we store the bitmap? Inside one block.

WHAT. The bitmap is data too, so it must live in blocks. ext4 makes a clean choice: the block bitmap is exactly ONE block.

WHY exactly one? Two reasons, both about simplicity and speed:

1. One block is one read — the OS grabs the entire "free map" for a region in a single disk access.
2. A fixed-size bitmap means the geometry is predictable: every region looks identical, so mkfs can place things by arithmetic instead of searching.

PICTURE. We take one block (orange), blow it up, and show it is a grid of $8B$ bits — because it is $B$ bytes and each byte is $8$ bits.

---

Step 4 — The killer constraint → blocks per group

WHAT. Now combine Step 2 and Step 3. The bitmap tracks $k$ blocks (needs $k$ bits). The bitmap is one block (holds $8B$ bits). A bit cannot describe a block it has no room for, so:

$k\le 8B.$

We take the largest region a single bitmap can fully cover, so we set $k=8B$. That region is a block group.

WHY set it to the maximum? Bigger groups = fewer groups = less repeated metadata and better locality of a file with its own map. But we cannot exceed $8B$, because bit number $8B+1$ simply does not exist in the block. So the maximum is the sweet spot the constraint hands us for free.

PICTURE. On the left, a bitmap block with $8B$ bits. Arrows fan out from it, each bit pointing at exactly one data block in a region of $8B$ blocks on the right. Every arrow lands; none is left over. That region is one block group.

---

Step 5 — Plug in the real number

WHAT. Substitute the common $B=4096$ bytes.

WHY. A formula is abstract; a smart 12-year-old should see the actual megabytes on their own disk.

$\text{blocks per group}=8\times 4096=32768.$

Now convert that many blocks into bytes:

$32768\text{blocks}\times 4096\frac{\text{bytes}}{\text{block}}=134,217,728\text{bytes}=128\text{MiB}.$

PICTURE. A single block group drawn to scale as a labelled bar: a thin orange bitmap slice at the front, then a thin inode-bitmap slice, then the inode table, then the wide band of $32768$ data blocks — the whole bar tagged "128 MiB".

---

Step 6 — Tiling the disk with groups (and the leftover case)

WHAT. The whole disk is just these $128$-MiB groups laid end to end. For a $10$ GiB disk:

$\text{number of groups}=\frac{10\times 1024\text{MiB}}{128\text{MiB}}=\frac{10240}{128}=80.$

WHY the division. Total capacity ÷ group size = how many groups fit. Each numerator/denominator carries the unit MiB, which cancels, leaving a pure count.

EDGE CASE — the disk is not a whole multiple. Real disks rarely divide evenly. If the last group would be partial, ext4 keeps it as a short final group: its bitmap still has $8B$ bits but the extra bits (for blocks that do not exist) are permanently marked used ($1$) so the allocator never hands them out.

PICTURE. Groups G0…G3 shown as equal orange bars, then a shorter final bar whose non-existent tail is hatched and marked "bits forced to 1 — never allocated."

---

Step 7 — Same idea for inodes → the group-of-an-inode formula

WHAT. Inodes are pre-numbered records ($1,2,3,\dots$). They are also split evenly across groups: a fixed count $I$ of inodes per group. To find which group inode $N$ lives in:

$\text{group}=\lfloor \frac{N-1}{I}\rfloor .$

WHY subtract 1? Inode numbers are 1-based (they start at $1$), but positions inside a group's table are 0-based (they start at $0$). The $-1$ shifts from counting-from-one to counting-from-zero. The floor bracket $\lfloor \cdot \rfloor$ means "throw away the fractional part" — it answers "how many whole groups fit before we reach inode $N$?"

WHY floor and not round? Rounding could push a boundary inode into the next group. Floor never overshoots: it lands you in the group that actually contains $N$.

PICTURE. A number line of inodes cut into groups of $I$. Inode $N$ sits inside one segment; a labelled bracket shows $(N-1)$ counted from the start, and the floor arrow snaps down to the group index.

---

The one-picture summary

Everything above is one chain: a byte is 8 bits → one block holds $8B$ bits → one bitmap block can only track $8B$ blocks → so a block group is $8B$ blocks → tile those across the disk → number inodes the same way and locate any one with a floor-divide. The figure below compresses that entire logical waterfall into a single flow.

Recall Feynman retelling — say it back in plain words

A disk is just a huge shelf of identical boxes, each box a block of $4096$ bytes. To use them, ext4 needs a checklist of which boxes are full. It writes that checklist as one bit per box — full or empty — and crams the whole checklist into a single box. But a box only holds $8\times 4096=32768$ bits, so one checklist can only keep track of $32768$ boxes. That is exactly why a block group is $32768$ blocks = $128$ MiB: the checklist can't watch any more than that. Chop the whole disk into these $128$-MiB chunks; a leftover partial chunk just marks its imaginary boxes as "full" so nobody uses them. Inodes (the little record cards, one per file) are numbered from $1$ and split the same even way, so to find which chunk card number $N$ lives in you subtract $1$ (because cards count from $1$ but slots count from $0$) and divide by the cards-per-chunk, throwing away the fraction. That's the whole geometry — one bitmap box decides the size of everything.

Recall Quick self-test

Blocks per group formula, in words? ::: One bitmap block holds $8B$ bits, each bit tracks one block, so a group is $8B$ blocks. Why 128 MiB for 4 KiB blocks? ::: $8\times 4096=32768$ blocks, times $4096$ bytes $=128$ MiB. Why the $-1$ in the inode-group formula? ::: Inodes count from $1$, table slots count from $0$; the $-1$ converts between them. What happens to a partial final group? ::: Its bitmap bits for non-existent blocks are forced to $1$ (used) so the allocator skips them.

See also: Operating Systems · ext2 vs ext3 vs ext4 · Hard links vs Symbolic links · Virtual File System · Journaling · Disk Scheduling · Memory Management.