File System
A file system is the part of an operating system, together with the on-disk format it defines, that organizes storage into named files and folders, tracks which blocks belong to what, and keeps the whole structure consistent. A raw disk is only a numbered array of fixed-size blocks; the file system is the set of rules and data structures written onto it that make "save this as report.docx in my documents" possible, and the same rules are what a different computer must understand to read the disk back.
A file system maintains a handful of structures, and the differences between systems are differences in how they build them. Every design needs metadata describing each file (size, timestamps, permissions), directories mapping names to files, and an allocation scheme recording which blocks are used or free. FAT, the file allocation table, keeps a table with one entry per block in which each entry points to the next block of the same file, a simple chain that is easy to implement but slow for random access and prone to fragmentation. Unix-style systems use inodes that point to a file's blocks directly or through indirect blocks, and many modern designs use extents, which describe a run of contiguous blocks in one record. When a disk is mounted, the operating system attaches its file system to the visible tree, which is why formatting a drive means writing a fresh, empty structure onto it.
The common file systems are best understood as products of their eras and platforms. FAT originated in Microsoft's disk software in 1977 and became the lingua franca of floppies, then of memory cards and USB sticks; FAT32 arrived with Windows 95 OSR2 in 1996 and cannot store a single file of 4 GiB or more, a limit that still surprises people copying large videos. Microsoft's NTFS shipped with Windows NT 3.1 in 1993 and added permissions, journaling, compression and large volumes. Linux's ext family began in 1992, with ext3 adding journaling in 2001 and ext4 in 2008, while Apple moved from HFS+ to APFS, introduced on iOS 10.3 and macOS High Sierra in 2017 with snapshots, cloning and strong support for flash storage. exFAT, from 2006, removed FAT32's size limits for removable media, and ZFS and Btrfs add checksums of data and built-in volume management.
Journaling exists because a crash in the middle of a multi-step update can leave a file system self-contradictory. Appending to a file touches the data, the file's size, the allocation map and the directory; if power fails after some steps but not others, blocks can be marked both used and free, or a file can point into the void. Older systems repaired this after a crash by scanning the whole disk with a tool such as fsck or chkdsk, which could take hours on large volumes. A journaling file system, as in NTFS, ext3, ext4 and others, first records its intended change in a log, so after a crash it merely replays or discards the few pending entries. Copy-on-write designs like APFS, ZFS and Btrfs avoid the problem differently, by never overwriting live structures and switching to a new consistent version in one atomic step.
Journaling protects the file system's structure, not necessarily the user's data, and that is a frequent misunderstanding. By default many journals record only metadata, so after a crash the structure is consistent but the last few seconds of a file's contents may be lost or stale. A journal is also not a backup: it cannot recover a deleted file, survive a failing drive or reverse ransomware encryption, whereas snapshot features in APFS, ZFS and Btrfs offer cheap point-in-time copies, which are still not independent backups. Another pitfall is portability, because a drive formatted as NTFS is read-only on some systems by default, APFS is Apple-specific and ext4 is not natively readable on Windows, so a USB drive meant for several platforms is typically formatted exFAT.
The file system has become a shaping force on data work as well. Distributed file systems such as HDFS and cloud object stores spread data across many machines, and training pipelines for large models are often bottlenecked by how quickly many small files can be listed and read, which is why datasets are packed into larger shard files. Case sensitivity (ext4 is case-sensitive, default NTFS and APFS are case-preserving but insensitive), maximum path length and the reliability of timestamps all vary, so code that works on one platform can fail on another purely because of the file system underneath.
Read a file system as the contract between raw storage and everything built on it: a set of structures that turn numbered blocks into names, folders and permissions, with journaling or copy-on-write as the discipline that keeps that contract intact when the power fails halfway through a sentence.