A lecture for the Operating Systems course at the Faculty of Informatics, Masaryk University, working up from what a file system is to what the hardware underneath is about to do to the design.

The starting point is deliberately dull. A file system organizes data on a storage medium into files and directories. Everything after that is consequence: how VFS lets Linux support dozens of different file systems behind one set of system calls, using operation tables for files, inodes, dentries and superblocks, and how the I/O stack fits together from the system call down through the page cache and the block layer to the device. Then the internals. Free space management, block allocators, and how blocks get addressed, direct and indirect blocks against extent trees.

Crash consistency is the part students find most interesting, because it is where a file system has to answer for itself. Journaling and copy-on-write solve the same problem in incompatible ways and neither is free. Journaling writes some things twice. Copy-on-write never overwrites anything, which costs you fragmentation and makes free space accounting genuinely hard. Delayed allocation and checksumming came next, both of which make more sense once you know which consistency model you are looking at.

The lecture closes on storage that does not behave like a disk. Shingled Magnetic Recording drives, where the write pattern every file system assumes is no longer valid. And Persistent Memory, which is fast enough, potentially tens of millions of IOPS, that the page cache and the block layer stop being help and start being the bottleneck. You do not fix that by optimizing the existing path. You bypass it, with mmap and XIP, and then you find out how much of the file system design quietly assumed a slow device.