A file system is the structure an operating system uses to organise raw storage into named files and directories, and to track where each file’s data physically lives.1
Overview
A storage device on its own offers only a flat array of numbered blocks. The file system imposes order on that array: it groups blocks into files, arranges files into a directory tree, records metadata such as names, sizes, timestamps, and permissions, and keeps track of which blocks are free. On Unix-like systems that metadata lives in a per-file inode that also holds the list of data blocks, while directories are just files that map names to inodes.
Common file systems include ext4 on Linux, NTFS on Windows, APFS on macOS, and the simple FAT family used on most SD cards and USB sticks. They differ in maximum file size, metadata richness, and crash behaviour. Many modern file systems are journaling: they log intended changes first, so after a crash or power loss the volume can be replayed to a consistent state instead of needing a slow full scan.
Inside it
The layers stack from the raw device up to the names a program uses:
| Layer | Holds | Example |
|---|---|---|
| Block | Smallest allocation unit | 4 KB block |
| Inode / record | One file’s metadata + block list | size, mode, mtime |
| Directory | Names mapped to inodes | captures/ |
| Journal | Pending changes for crash recovery | ext4 journal |
| Free-space map | Which blocks are unused | bitmap / extent tree |
Where it fits
The file system is the bridge between bare data storage hardware — an SSD, HDD, or flash card — and the files programs actually read and write. Before storage can be used it is formatted with a file system and mounted into the OS. GopherTrunk relies on it transparently: every decoded-call recording and IQ capture it writes becomes a file, and a journaling file system helps those logs survive an unexpected power cut at an unattended capture node.
Sources
-
File system — Wikipedia, on how operating systems organise storage into files and directories. ↩