What a Filesystem Actually Does
Linux Filesystems
Chapter 1 · What a Filesystem Actually Does
grub1-5 covered everything that happens before a filesystem exists — firmware, bootloaders, partition tables. This course picks up exactly where that left off, and resolves something linux1's own installer did silently: choosing partition sizes and confirming formatting, running the real operations this chapter finally explains.
The Layer Above the Partition Table
A partition table (MBR or GPT, per grub1-5) divides a disk into partitions — but a partition table entry says nothing about what kind of data actually lives inside a given partition. That's a filesystem's own job: the real structure organizing raw bytes into files and directories, imposed within a partition. This course starts exactly where grub1's own scope ended.
The VFS — One Interface, Many Filesystems
The Virtual Filesystem Switch (VFS) is a kernel abstraction layer that lets every program use the same system calls — open, read, write — regardless of which actual filesystem a given file happens to live on. This is exactly why plugging in a USB stick formatted with a completely different filesystem just works with the same ls/cp commands — the VFS translates underneath, invisibly.
Block Devices vs. Filesystems — A Real, Important Distinction
A block device (/dev/sda1) is a raw, undifferentiated sequence of blocks, addressable only by block number — genuinely no structure of its own. A filesystem is the structure imposed on top of that raw block device — inodes, directories, file data, metadata — turning "a big blob of bytes" into files and folders you can actually navigate.
mkfs (make filesystem) is the literal act of imposing that structure for the very first time — exactly the operation linux1's own installer ran silently, on your behalf, without ever explaining it.
Inodes, Superblocks, and a Preview of Journaling
- Superblock — metadata about the filesystem itself (size, block size, type, last-mounted time), stored at a known location, with backup copies elsewhere on disk for resilience
- Inode — metadata about one file (permissions, owner, size, timestamps, and pointers to its actual data blocks). Critically, the filename itself is not stored in the inode — a directory is just a mapping of names to inode numbers, a genuinely surprising fact worth sitting with; it's also exactly why a hard link works
- Journaling — previewed here, covered in full in
fs1-2's own ext4 chapter — keeps the filesystem consistent even if power is lost mid-write
Mounting — Attaching a Filesystem to the Directory Tree
mount takes a filesystem living on a specific block device and attaches it at a specific point in the overall directory tree — a mount point. Before mounting, that point is just an ordinary, empty directory; after, everything under it transparently belongs to the mounted filesystem.
A real /etc/fstab line — the persistent configuration for what mounts automatically at boot. Fields, left to right: the device (identified by UUID, more reliable than a device name that can shift between boots), the mount point, the filesystem type, mount options, the dump backup flag, and the fsck check order.
Resolving linux1's Own Glossed-Over Formatting Step
During Debian installation, linux1's own installer asked you to choose partition sizes and confirm formatting — silently running mkfs and writing a real fstab entry on your behalf, a genuine black box at the time. The actual mechanism is now on the table.
| What it actually is | Operations that make sense | |
|---|---|---|
| Block device | A raw sequence of addressable blocks, no structure | Reading/writing raw blocks, mkfs |
| Filesystem | The structure (inodes, directories, metadata) imposed on top | Creating/reading/writing files, mounting |
lsblk -f shows every block device alongside the filesystem type, label, and UUID actually living on it — a fast, direct way to see this chapter's own distinction reflected on a real, running system.
mkfs on a partition that already holds data is destructive by default on most systems — it does not check for or warn about existing data first. Always double- and triple-check the target device before running it; a real, common, costly mistake, in the same spirit as grub1's own repeated warnings about targeting the wrong device.
Hands-On Exercises
Explain, in your own words, why a partition table entry alone can't tell you what filesystem (if any) actually lives inside that partition.
📄 View solutionExplain why a file's name is not stored inside its own inode, and what this reveals about what a directory actually is.
📄 View solutionWrite a real fstab line that mounts a device with UUID 9a8b-7c6d as ext4 at /data, and explain what each field means.
📄 View solutionChapter 1 Quick Reference
- A partition table (grub1-5) divides a disk; a filesystem structures what's inside one partition
- The VFS gives every program the same open/read/write calls, regardless of the actual filesystem underneath
- Block device — raw, unstructured blocks; filesystem — the structure (inodes, directories, metadata) on top
- Superblock — metadata about the filesystem; inode — metadata about one file, with no filename stored in it
- mount attaches a filesystem to a directory tree location; fstab makes that persistent across reboots
lsblk -f— see block devices and their filesystems together, directly- mkfs is destructive by default — always confirm the target device first