File Systems in Operating Systems

Learning Objectives

By the end of this page, you should be able to:

• Explain what a file system does and why an OS needs one layered above raw storage devices.
• Describe contiguous, linked, and indexed allocation methods, and analyze their trade-offs.
• Explain the role of inodes, the superblock, and free-space management structures.
• Trace how directory structures map file names to data blocks.
• Explain what journaling does and why it protects against crash-induced corruption.
• Compare FAT32, NTFS, ext4, and APFS on structure, features, and typical use cases.
• Use commands like ls -i, stat, and df -T to inspect real file system metadata.

Quick Answer

A file system is the part of the operating system that organizes how data is stored, named, and retrieved on a storage device. It maps human-readable file names and directory paths onto the physical blocks of a disk or SSD, while tracking metadata (size, permissions, timestamps, ownership) separately from file content. Internally, it must decide allocation strategy (contiguous, linked, or indexed blocks), maintain free-space information so it knows which blocks are available, and often use journaling to log pending changes so a crash mid-write doesn't corrupt the whole volume. Different file systems — FAT32, NTFS, ext4, APFS — make different trade-offs here, which is why file size limits, permissions support, and crash recovery behavior vary across them. Understanding file systems matters because nearly every OS performance and reliability question (fragmentation, recovery after power loss, why large files behave differently) traces back to these design choices.

Core Content

What a File System Actually Does

Without a file system, a disk is just a flat sequence of addressable blocks — block 0, block 1, ..., block N. There's no concept of "files" or "folders" at that level. The file system is the abstraction layer that:

1. Lets you refer to data by a name ("essay.docx") instead of a block number.
2. Organizes names into a hierarchy (directories/folders).
3. Tracks metadata — size, owner, permissions, creation/modification time.
4. Decides where on disk each file's bytes physically live, and remembers that mapping.
5. Keeps track of free space so it can allocate new files without overwriting existing data.
6. Provides some resilience against partial writes caused by crashes or power loss.

Files and Directories

A file is a named collection of related data — could be text, an executable, an image, or a directory itself (a directory is really just a special file that stores a table of name → metadata-pointer entries).

A directory doesn't hold file content — it holds a list of (filename, inode number) or (filename, metadata pointer) pairs. This is why deleting a file's directory entry doesn't necessarily destroy its data immediately; it's why "unlinking" and "deleting" are related but distinct ideas in Unix.

Directory Structures

Most systems use a hierarchical (tree) structure:

Some systems support hard links, where two different directory entries point to the same underlying inode — the file effectively has two names and neither is the "original." A symbolic link, by contrast, is a small file whose content is just a path string pointing to another file — it's a redirect, not a shared identity. Deleting the target of a symlink leaves a dangling link; deleting one hard link just decrements a reference count, and the data survives as long as any hard link remains.

Allocation Methods

The central design problem: given a file that needs N blocks, how do we record which physical blocks belong to it?

1. Contiguous Allocation The file occupies a single unbroken run of blocks, recorded as (start block, length).

• Pros: Extremely fast sequential and random access (just start + offset); minimal metadata.
• Cons: Suffers from external fragmentation — over time, free space becomes a patchwork of small gaps too small for new files. Growing a file may require relocating it entirely if the following block is already taken.
• Used by: Some optical media (CD-ROM/ISO9660), and early systems where files were rarely resized.

2. Linked Allocation Each block stores a pointer to the next block in the file, like a linked list scattered across disk.

• Pros: No external fragmentation; files can grow by simply linking a new block anywhere free.
• Cons: No efficient random access — reading block 500 means following 500 pointers from the start. A single corrupted pointer can lose the rest of the file. Also wastes space per block for the pointer (mitigated by FAT — File Allocation Table systems, which move all the pointers into one central table instead of scattering them inside data blocks).

3. Indexed Allocation A dedicated index block holds an array of pointers to all the data blocks belonging to a file, rather than pointers being scattered through the data itself.

• Pros: Supports direct/random access without following chains; no external fragmentation.
• Cons: The index block itself is overhead; a single index block has limited pointer slots for very large files.
• Solution for large files: multi-level indexing — direct blocks for small files, single/double/triple indirect blocks for larger ones. This is exactly what Unix inodes use.

This is why in classic ext2/ext3, small files (under roughly 48 KB with 4 KB blocks) are reachable purely through the 12 direct pointers in the inode, while a multi-gigabyte file needs to walk through single, double, and even triple indirection.

Inodes

An inode (index node) is the metadata record for a file in Unix-like file systems. It stores:

• File type (regular file, directory, symlink, device, etc.)
• Permissions (owner/group/other read-write-execute)
• Owner UID/GID
• Size in bytes
• Timestamps (access, modify, change — atime, mtime, ctime)
• Link count (number of hard links pointing to it)
• Pointers to data blocks (direct + indirect, as shown above)

Crucially, the inode does not store the file's name — names live only in directory entries. This is why you can rename a file instantly (just edit the directory entry) without touching the file's actual data at all.

You can see this directly on a Linux system:

$ ls -i notes.txt
1245187 notes.txt

$ stat notes.txt
  File: notes.txt
  Size: 1024        Blocks: 8          IO Block: 4096   regular file
Device: 803h/2051d  Inode: 1245187     Links: 1
Access: (0644/-rw-r--r--)  Uid: (1000/  user)   Gid: (1000/  user)
Access: 2026-07-01 10:22:11
Modify: 2026-07-01 10:20:03
Change: 2026-07-01 10:20:03

ls -i prints the inode number; stat dumps the full inode metadata. If you create a hard link (ln notes.txt notes2.txt), both names will report the same inode number and the Links count becomes 2.

The Superblock and Free-Space Management

The superblock is a special block (usually near the start of the volume, with backup copies elsewhere) holding metadata about the file system as a whole: total block count, block size, free block count, inode table location, file system type/version, and a "clean/dirty" flag used during crash recovery. If the superblock is destroyed, the whole volume becomes unreadable — which is why file systems keep redundant copies.

Free-space tracking commonly uses one of:

• Bitmap: one bit per block, 1 = used, 0 = free. Compact and fast to scan for contiguous free runs.
• Free list: a linked list threading through all free blocks (conceptually the mirror of linked allocation).
• Grouping/counting: variations that store counts of contiguous free extents rather than per-block bits, common in extent-based systems like ext4.

Journaling

Journaling addresses a real hazard: if the system crashes or loses power while a multi-step metadata update is in progress (e.g., "remove entry from directory A, add entry to directory B, update inode"), the file system can be left in an inconsistent state — a classic power-loss corruption scenario.

A journaling file system first writes a description of the intended changes to a dedicated journal (log) area, then applies the actual changes, then marks the journal entry complete. On reboot after a crash, the file system replays any incomplete journal entries instead of running a slow, whole-disk consistency scan.

• ext4 journals metadata by default (data=ordered mode also ensures data blocks are written before the metadata that references them, avoiding stale-pointer corruption), with data=journal optionally journaling file data too (safer, slower).
• NTFS uses a similar log-based approach via its $LogFile, tracking metadata transactions for the Master File Table (MFT).
• Older FAT32 has no journaling at all — this is why FAT-formatted USB drives are especially prone to corruption after unsafe removal, and why chkdsk/fsck on FAT can take much longer, since it must scan the whole volume rather than replay a log.

Real File Systems

FAT32 (File Allocation Table 32) The simplest and most universally compatible format — used on USB drives and SD cards because virtually every OS and camera/device can read it. Uses linked allocation via a central File Allocation Table. Limitations: 4 GB maximum file size, no journaling, no permissions/ownership metadata, no support for symbolic links.

NTFS (New Technology File System) Windows' primary file system. Every file, including tiny ones, has an entry in the Master File Table (MFT) — for very small files, the data can even be stored directly inside the MFT record itself. Supports ACL-based permissions, encryption (EFS), compression, journaling via $LogFile, and very large volumes/files.

ext4 (Fourth Extended File System) The default on most Linux distributions. Uses inodes plus extents (a contiguous run of blocks described as start + length, more efficient than a huge indirect-pointer chain for large files), journaling, and backward compatibility with ext2/ext3.

APFS (Apple File System) Introduced by Apple for macOS/iOS, optimized for SSD/flash storage. Uses copy-on-write for crash safety (rather than a traditional write-ahead journal for file data), native encryption, and space sharing between multiple volumes on the same physical container.

Key Terms

Term	Definition	Context/Related
Inode	Metadata structure storing a file's attributes and pointers to its data blocks (not its name)	Used in ext4, and Unix-like file systems generally
Superblock	Block holding file-system-wide metadata (size, free blocks, inode table location)	Corruption of it can make an entire volume unreadable
Journaling	Logging intended changes before applying them, to allow fast crash recovery	ext4's $journal, NTFS's $LogFile
Contiguous allocation	Storing a file in one unbroken run of disk blocks	Fast access, prone to external fragmentation
Linked allocation	Each block points to the next block of the file	No fragmentation, poor random access
Indexed allocation	A dedicated index block lists all data block pointers for a file	Basis for Unix inode direct/indirect pointers
Extent	A (start block, length) descriptor for a contiguous run of blocks	Used by ext4 instead of per-block pointer chains
Master File Table (MFT)	NTFS's central table holding one record per file/directory	NTFS-specific; small files can be stored inline
Hard link	A second directory entry pointing to the same inode	Deleting one leaves data intact if link count > 0
Symbolic link	A small file whose content is a path to another file	Can dangle if target is deleted; cross-filesystem capable
Free-space bitmap	One bit per block marking used/free status	Common free-space tracking method

Common Mistakes

1. Misconception: "Deleting a file immediately erases its data from disk." Why it's wrong: Most delete operations just remove the directory entry (and decrement the inode's link count to zero), marking the blocks as free — the actual bytes remain on disk until overwritten by new data. Correct explanation: This is exactly why file-recovery tools can often "undelete" recently removed files, and why secure-delete tools must explicitly overwrite (zero out) blocks rather than just unlinking them.

2. Misconception: "Indexed allocation and linked allocation are basically the same idea." Why it's wrong: They differ fundamentally in where the pointers live. Linked allocation embeds a pointer to the next block inside each data block itself, forcing sequential traversal. Indexed allocation gathers all pointers into a separate index block, enabling direct/random access to any block without walking a chain. Correct explanation: Unix inodes are a refined indexed-allocation scheme (with direct + multi-level indirect pointers) precisely to get random access while still scaling to very large files.

3. Misconception: "Journaling means the file system never loses data after a crash." Why it's wrong: Journaling primarily protects metadata consistency (so the file system structure itself doesn't become corrupted), not necessarily every byte of in-flight file data. Depending on the journaling mode (e.g., ext4's data=ordered vs data=journal), unflushed data writes at the moment of a crash can still be lost even though the file system as a whole remains structurally sound. Correct explanation: Journaling guarantees the file system can recover to a consistent state quickly (no lengthy full-disk fsck), but full data-loss protection additionally depends on the journaling mode and whether the application itself called fsync().

Comparison and Connections

Allocation Method	Random Access	External Fragmentation	Growth Handling	Typical Use
Contiguous	Excellent	High	Difficult (may need relocation)	Optical media, static images
Linked	Poor (must traverse chain)	None	Easy (link anywhere free)	Historical/simple systems, FAT's table-based variant
Indexed	Good (direct index lookup)	None	Easy (add pointer/extent)	Unix inodes, ext4, NTFS

File System	Max File Size	Journaling	Permissions/ACLs	Typical Platform
FAT32	4 GB	No	No	USB drives, cameras, cross-platform media
NTFS	~16 TB (practically)	Yes ($LogFile)	Yes (ACLs)	Windows
ext4	~16 TB	Yes	Yes (POSIX permissions)	Linux
APFS	Very large (64-bit)	Copy-on-write, not classic journal	Yes	macOS, iOS

This page builds directly on Memory Management: both need to solve "track free space" and "map logical addresses to physical locations" — paging tables and inode indirect blocks are structurally similar problems. It also connects forward to Device Management and I/O Systems, since the file system ultimately issues read/write requests that travel through device drivers to physical storage hardware.

Practice Questions

Recall

1. What does an inode store, and what does it deliberately not store? Answer guidance: Stores type, permissions, owner, size, timestamps, link count, and data block pointers; does not store the file's name (names live in directory entries).
2. Name the three classic allocation methods discussed for mapping files to disk blocks. Answer guidance: Contiguous, linked, and indexed allocation.

Understanding 3. Why does linked allocation avoid external fragmentation while contiguous allocation does not? Answer guidance: Linked allocation can use any free block anywhere on disk since each block just points to the next one; it never needs a single unbroken run, so leftover scattered free blocks are still usable. Contiguous allocation requires one continuous run, so scattered small free gaps can't satisfy a request even if total free space is sufficient. 4. Explain why journaling reduces recovery time after a crash compared to a non-journaled file system. Answer guidance: A journaled FS only needs to replay the log of pending transactions recorded at crash time; a non-journaled FS (like FAT32) must scan the entire volume's metadata to detect and repair inconsistencies, which is far slower on large volumes.

Application 5. You run ls -i on two filenames and get the same inode number. What does this tell you, and what happens if you delete one of the names? Answer guidance: The two names are hard links to the same underlying file/inode. Deleting one name just removes that directory entry and decrements the link count; the data remains accessible via the other name until the link count reaches zero. 6. A 100 MB file needs to be stored on an ext-family file system using an inode with 12 direct pointers, single/double/triple indirect blocks. Explain qualitatively why direct pointers alone are insufficient here. Answer guidance: 12 direct pointers can only address a small, fixed amount of data (tens of KB at typical 4 KB block sizes); a 100 MB file needs vastly more blocks than 12, so the file system must use single/double indirect blocks (or extents) to reference the remaining data blocks.

Analysis 7. Compare why NTFS is well-suited to Windows enterprise environments while FAT32 remains common for USB flash drives, in terms of the features discussed. Answer guidance: NTFS offers ACL-based permissions, journaling, encryption, and large file/volume support needed for multi-user enterprise systems and reliability. FAT32 sacrifices those features for maximum cross-platform compatibility and simplicity — nearly any OS, camera, or device can read/write FAT32 without needing driver support for a more complex format. 8. A crash occurs on an ext4 volume mounted with data=ordered. What is and isn't guaranteed to survive, and why? Answer guidance: The file system's structural metadata (directory entries, inode tables, allocation bitmaps) is guaranteed to be consistent because it's journaled, and data=ordered ensures data blocks are flushed before the metadata pointing to them (avoiding stale/garbage data being referenced). However, data not yet flushed to disk before the crash (e.g., buffered writes not yet synced) can still be lost, since data=ordered does not journal file content itself.

FAQ

Q: Why can't I just use one universal file system for everything? A: Different environments need different trade-offs. Cross-platform portability (FAT32) sacrifices journaling and permissions; enterprise reliability (NTFS/ext4) needs journaling and access control at the cost of complexity; SSD-optimized systems (APFS) prioritize copy-on-write and wear-friendly patterns over classic in-place journaling. No single design wins on every axis.

Q: Is a directory a special kind of file? A: Yes, in Unix-like systems a directory is literally a file whose content is a table mapping names to inode numbers. It has its own inode too — that's why directories show up with a link count and permissions just like regular files.

Q: What's the practical difference between a hard link and a symbolic link? A: A hard link is another name pointing to the exact same inode — it cannot cross file systems and can't (normally) point to a directory. A symbolic link is a separate small file whose content is a path string; it can point across file systems or to directories, but breaks (dangles) if the target is moved or deleted.

Q: Why does formatting a large FAT32 drive take longer to check for errors than a similarly sized ext4 drive? A: FAT32 has no journal, so its checker (scandisk/chkdsk) must walk the entire allocation table and directory structure to verify consistency. ext4's fsck can rely on the journal to know exactly what was in-flight at crash time and only needs to fix that specific region, unless the file system was already flagged unclean for other reasons.

Q: Does journaling slow down normal file system performance? A: Slightly, since every metadata change (and optionally data change) gets written twice — once to the journal, once to its final location. Most systems default to journaling metadata only (not full data) specifically to balance this overhead against crash safety.

Quick Revision

• A file system maps names/paths to physical disk blocks and tracks metadata separately from content.
• Directories are just files listing (name, inode) pairs — they don't store file content.
• Contiguous allocation: fast, but suffers external fragmentation and hard to grow.
• Linked allocation: no fragmentation, but no random access (must follow the chain).
• Indexed allocation: separate index block lists all data pointers — enables random access; basis of inodes.
• Inode stores metadata + data block pointers, but never the file's name.
• Multi-level indirect pointers (single/double/triple) let inodes scale from tiny to huge files.
• Superblock holds file-system-wide metadata; its loss can make a whole volume unreadable.
• Free space is tracked via bitmaps, free lists, or extent counts.
• Journaling logs pending metadata (and sometimes data) changes so crash recovery replays the log instead of scanning the whole disk.
• FAT32 = simple, portable, no journaling, no permissions, 4 GB file limit.
• NTFS uses the Master File Table (MFT); ext4 uses inodes + extents; APFS uses copy-on-write, optimized for SSDs.

Related Topics

Prerequisites: Memory Management, Process Management

Related Topics: Storage Devices and Disk Scheduling, Virtual Memory, Operating System Security

Next Topics: Device Management and I/O Systems