Noesis
4.2.35 · D5Operating Systems

Question bank — ext4 structure — superblock, block groups, inodes

1,621 words7 min read↑ Back to topic
🇮🇳 Yeh page Hinglish mein padho →

True or false — justify

Every file on an ext4 filesystem has exactly one inode.
True. An inode is the identity of a file; the file is the inode. A file can have many names (hard links) but only ever one inode — that is why the inode, not the name, holds the link count.
A directory does not have an inode of its own.
False. A directory is just a special file whose data is a table of (name → inode number) pairs, so it needs its own inode to store its mode, size, and data-block location — see Hard links vs Symbolic links for why names live in that table.
The superblock lives at block 0 of the disk.
False. The first 1024 bytes are reserved for a boot sector, so the primary superblock sits at byte offset 1024. Block 0 is left alone.
Deleting a hard link always frees the file's data blocks.
False. Deleting a link only decrements the inode's link count; data is freed only when that count reaches 0 and no process still has the file open.
The block bitmap and the inode bitmap are the same size.
False in meaning, often equal in bytes. Both are exactly one block, but the block bitmap has one bit per block while the inode bitmap has one bit per inode in the group — they track different pools that happen to fit in one block each.
Backup superblocks contain the same core geometry as the primary.
True. That is the entire point of redundancy: if the primary at offset 1024 is corrupted, fsck can rebuild from a backup because the backup describes the identical block size, counts, and layout.
Extents replace the idea of a file's byte offset — you no longer need logical block numbers.
False. Extents still map logical block ranges to physical ranges; they just describe many contiguous blocks in one record instead of one pointer per block. Logical offsets are how the OS still finds byte .
An empty file (0 bytes) still consumes an inode.
True. The inode exists the moment the file is created, holding mode, owner, and timestamps; it costs an inode-table slot even with zero data blocks. This is exactly why df -i can hit 0 while df shows free space.
Block groups are pointless on SSDs because SSDs have no seek time.
False. Locality was the original motive, but groups also bound bitmap size, localize related metadata, and reduce fragmentation — all still valuable on flash. See ext2 vs ext3 vs ext4.
The magic number 0xEF53 is the filesystem's UUID.
False. 0xEF53 is a fixed constant identifying the filesystem type (ext2/3/4); the UUID is a unique per-filesystem identifier stored separately in the superblock.

Spot the error

"Inode 0 is the root directory, so path resolution starts there."
Two errors: inode numbering is 1-based (there is no inode 0 as a normal file), and the root is inode 2 (inodes 1–10 are reserved). Resolution begins at inode 2.
"To rename a file, ext4 rewrites the inode with the new name."
The inode never held the name. Renaming only edits the directory entry (or moves the entry to another directory's data), leaving the inode untouched.
"A group holds inodes because the inode bitmap is one block."
The formula gives blocks per group, driven by the block bitmap. Inodes-per-group is an independent mkfs parameter (e.g. 8192), not forced to .
"Since the superblock stores free counts, reading it tells you exactly which blocks are free."
The superblock stores how many are free, not which. The per-group block bitmap answers "which"; the superblock only summarises totals — see Bitmaps for allocation.
"ext4 journals file data by default so no bytes are ever lost on a crash."
By default ext4 journals metadata (ordered mode), not full data. Full data journaling exists but is opt-in and slower. See Journaling.
"A symbolic link and a hard link both share the target's inode."
Only a hard link shares the inode. A symbolic link is a separate file whose data is a text path to the target, with its own inode — Hard links vs Symbolic links.
"The inode table is allocated as files are created, so it grows on demand."
The inode table is pre-allocated at format (mkfs) time. Its size is fixed forever; you cannot grow the inode pool later without reformatting.

Why questions

Why is the filename kept in the directory and not in the inode?
So multiple names can point to one inode (hard links). If the name lived in the inode, one file could have only one name, and hard links would be impossible.
Why does the single block bitmap cap the size of a block group?
The bitmap must have one bit per block it tracks and is exactly one block ( bits). You cannot track more blocks than you have bits, so the group can hold at most blocks.
Why does ext4 place metadata (inode table, bitmaps) inside each group rather than all at the disk's front?
To keep a file's inode physically near its data, minimising head travel on disk and localising the metadata a bitmap describes — a locality argument tied to Disk Scheduling.
Why prefer extents over ext2/3 indirect block pointers for large files?
One extent describes a whole contiguous run (e.g. 100 blocks) in a single record, whereas indirect pointers need one pointer per block. Extents are far more compact and faster to walk.
Why must group/index math use ?
Inode numbers are 1-based but the inode table is a 0-based array. Skipping the shifts every calculation and lands you in the wrong group exactly at group boundaries.
Why can a full filesystem still refuse to create a new file?
Files need a free inode, a separate fixed pool set at format time. Exhausting inodes (millions of tiny files) blocks creation even with free bytes — the classic df vs df -i split.
Why is the superblock duplicated but the inode table is not?
The superblock is a single point of failure describing the whole filesystem, so redundancy is cheap and vital. The inode table is huge and per-group; duplicating it would waste enormous space, and its loss is localised.

Edge cases

What is the link count of a brand-new, empty directory?
Two. One entry from its parent points to it, and its own . entry points to itself — both count as hard links to the directory's inode.
What happens to open file descriptors when the last hard link is removed while a process still reads it?
The directory entry vanishes so the name is gone, but the inode and its data survive until the process closes the descriptor; the link count is 0 but the open count is not.
If a disk size is not a whole multiple of the group size, what happens to the last group?
The final block group is simply shorter — it holds fewer data blocks. Its bitmap marks the non-existent blocks as used so allocation never hands them out.
Can inode number 0 ever be assigned to a file?
No. Inode 0 is used as the "no inode / empty" sentinel in directory entries, so a valid file never has inode 0 — this is why numbering starts at 1.
What does a directory entry pointing to a deleted file's slot look like?
Its inode field is set to 0, marking the slot free/unused so future lookups skip it and new entries can reuse the space.
If block size were 1 KiB instead of 4 KiB, how does group geometry change?
Blocks per group falls to blocks, so each group spans only — smaller groups, more of them, and larger relative metadata overhead.
Recall One-line self-test before you leave

Cover this and answer: Where is the filename, which inode is root, and what caps a block group's size? Filename ::: in the directory entry (name → inode number), never in the inode. Root inode ::: inode 2 (1–10 reserved). Group size cap ::: the single block bitmap — bits means at most blocks per group.