map / Concepts / Storage

Concepts Core ~45 min requires: Operating Systems

Storage

Everything above a flash cell is an abstraction: blocks, inodes, filesystems, caches. Understand the stack and the scariest storage incidents become routine.

Q1A file is an inode, not a namewarm-up

The name in a directory just points to an inode — the real file (data + metadata). Two names can point to one inode: a hard link.

Task

Create a file, hard-link it, and prove both names share one inode.

Verify it yourself

verify

$ ls -li a b

Both lines show the same inode number and a link count of 2. The name is just a label on the inode.

Reveal solution

solution

$ echo hi > a
$ ln a b
$ ls -li a b

Q2Make a filesystem inside a filecore

A filesystem is just a format written onto a block device. A plain file can be a block device via a loop mount — the trick containers and disk images use.

Task

Create a 64 MB image, format it ext4, mount it, and confirm it's usable.

Verify it yourself

verify

$ df -h /mnt/loop

/mnt/loop shows a ~60 MB ext4 filesystem — one you conjured out of an ordinary file.

Reveal solution

solution

$ dd if=/dev/zero of=disk.img bs=1M count=64
$ mkfs.ext4 disk.img
$ sudo mkdir -p /mnt/loop
$ sudo mount -o loop disk.img /mnt/loop
$ df -h /mnt/loop

Q3Disk full, but du disagreesdebug

The classic: df says the disk is full, du can't find the space. The culprit is a deleted file still held open — the space isn't freed until the last fd closes. (Remember fds from OS.)

Task

Create a process holding a large deleted file, then find it.

Verify it yourself

verify

$ sudo lsof +L1 2>/dev/null | grep deleted | head

lsof shows a file with link-count 0 (deleted) still open. Killing that process — not rm — is what actually frees the space.

Reveal solution

solution

$ python3 -c "f=open('big','wb'); f.write(b'x'*50_000_000); f.flush(); import os; os.remove('big'); import time; time.sleep(300)" &
$ df -h .   # space used
$ du -sh big 2>/dev/null   # nothing — it is gone from the tree
$ sudo lsof +L1 2>/dev/null | grep deleted

Reach engineers who read the man page

Native, contextual, no tracking — this is how the curriculum stays free.

Q4Watch the page cachecore

Linux caches file data in free RAM (the page cache) so reads are fast and writes are buffered. That's why the second read is instant — and why free shows "buff/cache".

Task

Write a file, watch cache grow, then drop the caches and watch it fall.

Verify it yourself

verify

$ free -h

The buff/cache column jumps after the write and drops after you clear it. That memory isn't "used up" — it's reclaimable cache.

Reveal solution

solution

$ dd if=/dev/zero of=testfile bs=1M count=200
$ free -h
$ sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
$ free -h

Q5No space left — with space leftdebug

You get No space left on device, but df -h shows free space. The disk isn't out of bytes — it's out of inodes. Millions of tiny files will do this.

Task

Learn the one command that reveals inode exhaustion.

Verify it yourself

verify

$ df -i

df -i shows inode usage per filesystem. If IUse% is 100% while df -h shows free space, you've found it — clean up small files or reformat with more inodes.

Reveal solution

solution

$ df -h    # shows free bytes
$ df -i    # shows the real problem: inodes

What you just built

Inodes, loop devices, the page cache, and inode exhaustion are exactly the concepts Docker's overlayfs and Kubernetes' persistent volumes are built on. You'll see them again — now you know what they are.