Worked examples — ext4 structure — superblock, block groups, inodes

---

The scenario matrix

Every question about ext4 geometry is really one of a small handful of shapes. Here is the full list — each later example is tagged with the cell it fills.

#	Case class	What makes it tricky	Example
A	Inode → block group (normal)	the 1-based offset	Ex 1
B	Inode → block group (boundary)	inode exactly at a group edge	Ex 2
C	Degenerate input: inode 1	smallest legal inode, off-by-one trap	Ex 3
D	Capacity from geometry	metadata overhead vs raw size	Ex 4
E	Zero/limiting: tiny disk	disk smaller than one group	Ex 5
F	Inode table sizing	inodes are a separate fixed pool	Ex 6
G	Real-world word problem	"millions of tiny files" — runs out of inodes not space	Ex 7
H	Extents vs old pointers	how many extent records for a fragmented file	Ex 8
I	Exam twist: different block size	geometry scales with $B$; don't hardcode 4096	Ex 9
J	Usable data blocks per group	subtracting ALL metadata blocks	Ex 10

Two symbols recur, so let's pin them down once, in plain words:

Recall The one formula that solves cells A, B, C

For an inode numbered $N$ (numbering starts at 1) with $I$ inodes per group:

• Group number ::: $\lfloor \frac{N-1}{I}\rfloor$
• Index inside that group's inode table ::: $(N-1)\mathrm{mod}I$
• Why subtract 1? ::: inode numbers are 1-based, array slots are 0-based; skipping this puts you one group off at every boundary.

---

A picture of the mapping (read this before Case A)

The figure below is the whole page in one image: on the left, the inode-number line chopped into equal groups of $I$; on the right, the physical layout of a single block group (superblock backup → bitmaps → inode table → data). Every worked example is just "which arrow am I following?"

In words: inode numbers $1\dots I$ live in group 0, $I+1\dots 2I$ in group 1, and so on — the vertical dashed lines are the group boundaries that Case B lands exactly on. Inside one group (right panel), the first few blocks are metadata; the big green stretch at the end is where file data actually goes (that green stretch is what Case J counts).

---

Case A — Inode to block group, the ordinary case

Follow the blue arrow in the figure above: it takes inode $50000$ from the left number-line into some group box.

Step 1 — Shift to 0-based. $N-1=50000-1=49999$ Why this step? The formula counts how many inodes come before $N$. Inode 1 is the "zeroth" inode, so we subtract 1 to turn a 1-based label into a 0-based position.

Step 2 — Divide by the group size, keep the whole part. $\text{group}=\lfloor \frac{49999}{8192}\rfloor =\lfloor 6.103\dots \rfloor =6$ Why this step? Every group holds exactly $I=8192$ inodes. Integer division "how many full groups fit before us" is the group number. The floor throws away the fractional part because you can't be in "group 6.1".

Step 3 — Remainder gives the slot. $(N-1)\mathrm{mod}I=49999\mathrm{mod}8192=49999-6\times 8192=49999-49152=847$ Why this step? The remainder is "how far into group 6 we are" — the row of the inode table (the right panel of the figure).

Verify: reconstruct the inode from (group, index): $6\times 8192+847+1=49152+847+1=50000$. ✅ (the $+1$ undoes the 0-based shift).

---

Case B — Boundary: an inode sitting exactly on a group edge

In the figure, these two inodes sit on either side of the first dashed boundary line.

Step 1 — Do inode 8192. $\lfloor \frac{8192-1}{8192}\rfloor =\lfloor \frac{8191}{8192}\rfloor =\lfloor 0.9998\dots \rfloor =0$ Why this step? $8191<8192$, so the whole part is $0$. Inode 8192 is the last inode of group 0 (index $8191$).

Step 2 — Do inode 8193. $\lfloor \frac{8193-1}{8192}\rfloor =\lfloor \frac{8192}{8192}\rfloor =1$ Why this step? Now the numerator equals the group size exactly, so the whole part ticks over to $1$. Inode 8193 is the first inode of group 1 (index $0$).

Verify: group 0 holds inodes $1\dots 8192$ (that's exactly $8192$ inodes), group 1 starts at $8193$. Count checks out. ✅

---

Case C — Degenerate input: the smallest legal inode

This is the very first slot on the left of the figure.

Step 1 — Apply the formula literally. $\text{group}=\lfloor \frac{1-1}{8192}\rfloor =\lfloor \frac{0}{8192}\rfloor =0,\text{index}=0\mathrm{mod}8192=0$ Why this step? This is the whole reason the formula subtracts 1: the first inode must map to slot 0 of group 0. If we forgot the $-1$ we'd still get group 0 here (since $\lfloor 1/8192\rfloor =0$), so this case hides the bug — that's why you must test boundaries (Ex 2), not just inode 1.

Verify: reconstruct $0\times 8192+0+1=1$. ✅ The smallest inode maps to the first slot, as it must.

---

Case D — Capacity from pure geometry

Step 1 — Put both sizes in the same unit (MiB). $10\text{GiB}=10\times 1024\text{MiB}=10240\text{MiB}$ Why this step? You can't divide a size by a group-size unless the units match. Mixing GiB and MiB is the #1 arithmetic error here.

Step 2 — Divide by group size. $\frac{10240\text{MiB}}{128\text{MiB/group}}=80\text{groups}$ Why this step? Number of groups is just total-size ÷ size-per-group. The metadata (bitmaps, inode table, superblock backups) is carved out of each group, so it does not change the group count — it eats into the usable data blocks within a group.

Verify: $80\times 128=10240$ MiB $=10$ GiB exactly. ✅ Clean because $10240$ is a multiple of $128$.

---

Case E — Limiting case: a disk smaller than one group

Step 1 — Compute the raw ratio. $\frac{64\text{MiB}}{128\text{MiB}}=0.5$ Why this step? The disk is half a group. But you cannot have half a block group — a group is the unit of layout.

Step 2 — Round up with ceiling. $\text{groups}=\lceil 0.5\rceil =1(\text{but the single group is only half-full})$ Why this step? We use ceiling (defined above) because even a fraction of a group still needs one whole group to live in. ext4 makes one group and simply tracks fewer blocks in it: the block bitmap still occupies a full block, but many of its bits mark "beyond end of device" as used. So a small disk pays proportionally more metadata overhead — the degenerate case where "one bitmap block" is oversized for the data.

Verify: blocks actually present $=64\text{MiB}/4096=64\times 1024\times 1024/4096=16384$ blocks. That's fewer than the $32768$ bits a full bitmap holds, so one bitmap covers them all with room to spare. ✅ Confirms exactly one group.

---

Case F — Inode table sizing (inodes are a separate pool)

Step 1 — Total bytes of the inode table. $8192\times 256=2,097,152\text{bytes}$ Why this step? The inode table is a plain array: (count) × (size of one record).

Step 2 — Convert bytes to blocks, rounding up. $\lceil \frac{2,097,152}{4096}\rceil =\lceil 512.0\rceil =512\text{blocks per group}$ Why this step? Disk is allocated in whole blocks, so in general you must round up (ceiling) — if the array were, say, $2,097,200$ bytes you'd still need $513$ blocks because the leftover bytes demand one more whole block. Here it divides evenly, so ceiling and floor agree at $512$. $512$ blocks dwarfs the $2$ bitmap blocks — inode tables are the bulk of fixed metadata.

Verify: $512\times 4096=2,097,152$. ✅ And $512$ blocks $=2$ MiB, out of a $128$ MiB group — about $1.6\%$ of the group is inode table.

---

Case G — Real-world word problem: running out of inodes

Step 1 — Total inodes on the volume. $80\text{groups}\times 8192\text{inodes/group}=655,360\text{inodes}$ Why this step? Inodes are pre-allocated at mkfs time — a fixed pool. Every file needs exactly one. Once all $655,360$ are used, no new file can be created regardless of free bytes.

Step 2 — Check the space side (upper bound). Take the worst case where each file still occupies one full $4096$-byte block: $655,360\times 4096=2,684,354,560\text{bytes}$ Convert to GiB (1 GiB $=1024^3=1,073,741,824$ bytes): $\frac{2,684,354,560}{1,073,741,824}=2.5\text{GiB}$ Why this step? Even in this worst case only $2.5$ GiB of the $10$ GiB is touched — confirming the two resources decoupled: files (inodes) hit their limit while bytes did not.

Step 3 — Diagnose. df -i would show $100\%$ inodes used; df shows space free. Fix: delete files or reformat with more inodes (mkfs.ext4 -N or -i bytes-per-inode).

Verify: the failure count equals the inode pool: $655,360=80\times 8192$, and the worst-case space $655,360\times 4096=2,684,354,560$ bytes $=2.5$ GiB exactly. ✅

---

Case H — Extents vs old block pointers

Reading the figure: the top blue bar is a $400$-block file stored contiguously — it collapses into a single extent record (start $=5000$, length $=400$), shown by the one arrow on the right. The bottom three bars (green / orange / red) are the same file broken into 3 separated runs on disk — now you need 3 extent records, one per contiguous run, still fitting in the inode's 4 inline slots. The gray line at the bottom reminds you that ext2/3 would instead store one pointer per block ($400$ of them) plus an indirect block. The pedagogical punch: extent count grows with the number of fragments, not the number of blocks.

Step 1 — Contiguous file. One run of $400$ blocks $\Rightarrow$ 1 extent (top bar in the figure). Why this step? An extent's whole point is that contiguity collapses into a single (start, length) pair. $400$ blocks, one record.

Step 2 — 3-piece file. Three runs $\Rightarrow$ 3 extents, all fitting in the inode's $4$ inline slots (no B-tree needed). Why this step? One extent per contiguous run, not per block. $3\le 4$, so no external tree.

Step 3 — Contrast ext2/3. The old scheme stores one 4-byte pointer per data block: $400$ pointers. The first $12$ are direct; the rest ($400-12=388$) live in a single indirect block. That indirect block holds $B/4=4096/4=1024$ pointers (we divide by $4$ because each pointer is $4$ bytes), which is $\ge 388$, so one indirect block suffices. Net: ext2/3 needs $1$ extra indirect block of metadata plus $400$ pointer entries — versus ext4's $1$ extent record. Why this step? Shows why extents win: metadata grows with the number of fragments, not the number of blocks.

Verify: contiguous ⇒ $1$ extent; ext2/3 indirect block holds $4096/4=1024$ pointers $\ge 388$ needed, so exactly one indirect block suffices. ✅

---

Case I — Exam twist: change the block size

Step 1 — Recompute blocks per group from the definition. $\text{blocks per group}=8B=8\times 1024=8192\text{blocks}$ Why this step? $32768$ was never a constant — it was $8B$ evaluated at $B=4096$. The bitmap constraint (one bit per block, one bitmap block per group) scales with $B$. Memorising the number instead of the formula is the trap.

Step 2 — Group size in bytes. $8B^2=8\times 1024^2=8\times 1,048,576=8,388,608\text{bytes}=8\text{MiB}$ Why this step? Group size is (blocks/group) × (bytes/block) $=8B\times B=8B^2$. Quadratic in $B$ — shrinking $B$ by $4\times$ shrinks group size by $16\times$ ($128\text{MiB}\to 8\text{MiB}$).

Verify: $8192\times 1024=8,388,608=8\text{MiB}$. And the ratio to the 4 KiB case: $128\text{MiB}/8\text{MiB}=16=4^2$. ✅ Quadratic scaling confirmed.

---

Case J — Usable data blocks per group

This is the green data stretch in the right panel of the very first figure — everything after the metadata blocks.

Step 1 — List every metadata block per group. $\underset{\text{sb backup}}{\underbrace{1}}+\underset{\text{GDT}}{\underbrace{1}}+\underset{\text{block bitmap}}{\underbrace{1}}+\underset{\text{inode bitmap}}{\underbrace{1}}+\underset{\text{inode table}}{\underbrace{512}}=516\text{blocks}$ Why this step? You cannot just subtract "the bitmaps" — every fixed structure the group carries eats blocks. Missing one term is the usual exam slip. (Groups without a superblock backup save those 2 blocks, but the worst case is the safe one to quote.)

Step 2 — Subtract from the group total. $32768-516=32252\text{data blocks per group}$ Why this step? Data blocks are whatever remains after all fixed metadata is carved out — this is the number a group can actually store files in.

Step 3 — Overhead as a percentage. $\frac{516}{32768}\approx 0.01575=1.575\%$ Why this step? Turning the loss into a fraction tells you the metadata "tax". Under $2\%$ here — inode tables dominate it.

Verify: $32252+516=32768$ (accounts for every block), and $32252\times 4096=132,104,192$ bytes $\approx 126$ MiB of usable data per $128$ MiB group. ✅

---

The chain, at a glance

---

Self-test

Recall Quick recall

Group of inode 8192 with I=8192 ::: group 0 (last inode of group 0, since floor(8191/8192)=0) Blocks per group when B=1024 ::: 8×1024 = 8192 blocks (8 MiB group) Extents for a perfectly contiguous 400-block file ::: exactly 1 extent Why does a 64 MiB disk still get a full bitmap block ::: the bitmap is one whole block regardless; unused bits are marked used df shows free space but files won't create — cause ::: inode pool exhausted (separate fixed pool); check df -i Usable data blocks per group (B=4096, 512-block inode table, 4 other metadata blocks) ::: 32768 − 516 = 32252 data blocks What does $a\mathrm{mod}m$ equal precisely ::: $a-m\lfloor a/m\rfloor$, always in the range $0\dots m-1$ Why ceiling (not floor) for "how many blocks to store X bytes" ::: any leftover bytes still need one more whole block, so you round up

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