Module 4 · Unit 10 · Lesson 7 of 7
Modern File Systems
The previous six lessons presented the file system's concepts one at a time: the file and the directory, the inode and the metadata, the directory's internal structure, the allocation of a file's blocks, and the journal that keeps the metadata consistent across crashes. This lesson puts the pieces back together and surveys the file systems that run the world's storage today — ext4, XFS, Btrfs, ZFS, and the flash-specific file systems. It shows how each system combines the concepts, what trade-offs it makes, and how to choose among them.
01 Introduction
Lesson 10.1 introduced the file as a named sequence of bytes and the directory as a mapping from names to inodes. Lesson 10.2 examined the metadata that the inode holds, and Lesson 10.3 presented the inode itself. Lesson 10.4 turned to the directory's internal structure, showing how the name-to-inode mapping is stored and searched. Lesson 10.5 presented file allocation — the mapping from a file's logical blocks to physical blocks — and Lesson 10.6 presented journaling, the mechanism that keeps the metadata consistent across crashes. This lesson is the unit's capstone: it presents the modern file systems that combine these concepts, and it shows how the design choices interact.
A modern file system is not simply a file system that is currently in use; it is a file system whose design reflects the last three decades of research and engineering. The modern file systems share a set of design trends: they use extents rather than single-block indexing (Lesson 10.5); they use B-trees for their directories and metadata (Lesson 10.4); they use checksums to detect corruption; they use journaling or copy-on-write for crash consistency (Lesson 10.6); they integrate snapshots and RAID into the file system itself; and they support compression and deduplication as first-class features. The trends are not universal — ext4 uses journaling but not copy-on-write, XFS uses B-trees but not snapshots — but they define the space in which the modern file systems live.
The lesson is organized as a survey. It begins with the criteria that define a modern file system and the workloads that drive the design. It then presents the four general-purpose file systems — ext4, XFS, Btrfs, and ZFS — one at a time, describing each one's design, features, and trade-offs. It presents the flash- specific file systems (F2FS and the flash-friendly approaches) that address the characteristics of solid- state storage. It presents the comparison of the systems, and it closes with the criteria for choosing a file system for a workload. The lesson is the unit's synthesis: it shows how the concepts from Lessons 10.1 through 10.6 appear in the systems that users actually deploy.
Prerequisites
This lesson builds directly on Lessons 10.1 through 10.6. The file and directory model, the inode, the directory's internal structure, the allocation methods (contiguous, linked, indexed, extents), and the journaling mechanism are all assumed. The discussion of checksums assumes the concept of metadata corruption from Lesson 10.6, and the discussion of copy-on-write assumes the extent-based allocation from Lesson 10.5. The discussion of RAID and flash storage is a preview of Unit 11 (I/O and Storage Management), but no new storage concepts are introduced — the file systems' RAID and flash support is described in terms of the file system's own structures. Familiarity with the Linux command line from Lesson 2.2 is helpful, since the interactive activity uses standard Unix tools.
02 Learning objectives
By the end of this lesson you will be able to
- Describe the design trends that define a modern file system and explain the workloads that drive them.
- Describe ext4's design, features, and trade-offs, and explain its relationship to ext2 and ext3.
- Describe XFS's design, features, and trade-offs, and explain its suitability for large file systems and parallel workloads.
- Describe Btrfs's design, features, and trade-offs, and explain how its copy-on-write approach provides snapshots, checksums, and RAID.
- Describe ZFS's design, features, and trade-offs, and explain its pooled storage and end-to-end integrity model.
- Describe the flash-specific file systems (F2FS) and explain how they address the characteristics of solid-state storage.
- Compare the modern file systems and choose an appropriate file system for a given workload.
This lesson contributes to U10.7 and the unit's synthesis, and to course learning outcomes CLO1, CLO5, CLO7, and CLO8.
03 Required reading
- Operating System Concepts — Chapter 15, File-System Internals, and Chapter 16, Security. The treatment of the file system's structure and the survey of the file systems in use.
- OSTEP — Chapter 41, Locality and The Fast File System, and Chapter 42, Crash Consistency: FSCK and Journaling. OSTEP's treatment of the Fast File System's design is the basis for understanding the modern file systems' lineage, and its treatment of crash consistency is the basis for understanding the journaling and copy-on-write approaches.
- Tanenbaum & Bos — Modern Operating Systems, Chapter 4, File Systems. A systematic treatment of the file system's design space, including the modern systems' approaches.
- Mathur, A., Cao, M., Bhattacharya, S., Dilger, A., Tomas, A., & Vivier, L. — The New Ext3 Directory Index. Ottawa Linux Symposium, 2007. The paper that describes the HTree directory, the basis of ext3 and ext4's directory indexing.
- Rodeh, O., Bacik, J., & Mason, C. — BTRFS: The Linux B-Tree Filesystem. ACM Transactions on Storage, 2013. The design of Btrfs's copy-on-write consistency model, its snapshots, and its checksums.
- Bonwick, J., & Moore, B. — ZFS: The Last Word in File Systems. Sun Microsystems, 2007. The design of ZFS's pooled storage and end-to-end integrity model.
- Lee, C., Sim, D., Hwang, J., & Cho, S. — F2FS: A New File System for Flash Storage. USENIX FAST, 2015. The design of F2FS, the flash-friendly file system.
- Sweeney, A., Doucette, D., Hu, W., Anderson, C., Nishimoto, M., & Peck, G. — Scalability in the XFS File System. USENIX Annual Technical Conference, 1996. The design of XFS's allocation groups and its scalability.
-
Linux man pages:
man 5 ext4,man 5 xfs,man 5 btrfs,man 5 zfs(if available),man 5 f2fs,man 8 mkfs.ext4,man 8 mkfs.xfs,man 8 mkfs.btrfs,man 8 mkfs.f2fs,man 8 btrfs,man 8 xfs_info,man 8 tune2fs,man 1 df,man 1 lsblk.
Reading strategy
Read the Silberschatz chapter first for the survey of the file systems in use, and the OSTEP chapters for the design principles that the modern systems inherit from the Fast File System. Then read the primary sources for each file system — the Btrfs paper for copy-on-write and snapshots, the ZFS paper for pooled storage and end-to-end integrity, the F2FS paper for flash-specific design, and the XFS paper for allocation groups and scalability. The papers are dense, but they repay close reading: each one presents a different answer to the same design questions, and the differences are instructive. Finally, the Linux man pages are the practical view — the options, features, and tools that administrators actually use. Pay particular attention to the difference between the file systems' features (extents, checksums, snapshots, RAID) and their implementation strategies (journaling versus copy-on-write, in-place versus out-of-place updates). The features are what users see; the strategies are what the file system's designers chose to achieve them.
04 Core content
4.1 What makes a file system "modern"?
The term modern file system is not precise, but it has a recognizable meaning. A modern file system is one whose design reflects the last three decades of research and engineering, and whose feature set addresses the workloads of the present. The modern file systems share a set of design trends:
- Extents
- The file system describes a file's layout as a list of extents — ranges of contiguous blocks — rather than as a list of individual block pointers. Extents reduce the metadata overhead for large files and allow the file system to allocate and read large contiguous regions efficiently. ext4, XFS, Btrfs, ZFS, and NTFS all use extents.
- B-tree metadata
- The file system organizes its metadata — the directory entries, the extent lists, the free-space information — as B-trees. B-trees provide O(log n) lookups and, because they store keys in sorted order, efficient range queries. XFS, Btrfs, and ZFS use B-trees pervasively; ext4 uses a B-tree-shaped structure (the HTree) for its directories and an extent tree for its large files.
- Checksums
- The file system computes and stores a checksum for every metadata block (and, in the most thorough systems, for every data block). The checksums detect corruption: a block whose checksum does not match is known to be corrupt, and the file system can refuse to use it or recover it from a replica. ZFS and Btrfs checksum all data; ext4 and XFS checksum metadata by default.
- Journaling or copy-on-write
- The file system provides crash consistency, either by journaling its metadata (ext4, XFS) or by never overwriting a block in place (Btrfs, ZFS). The journaling approach is simpler and more efficient for the common case; the copy-on-write approach provides snapshots and integrity as natural by-products.
- Snapshots and clones
- The file system can take a point-in-time snapshot of its state and, in some systems, create a writable clone of a file or a subvolume. The snapshots are cheap (they do not copy data), and they are the basis for backup, testing, and versioning workflows. Btrfs and ZFS provide snapshots as a first-class feature; ext4 and XFS provide them only through external tools (LVM snapshots).
- Integrated RAID and pooling
- The file system manages multiple devices directly, spreading its data across them, mirroring it, or both, without a separate volume manager. ZFS's storage pools and Btrfs's profiles are the modern examples; ext4 and XFS rely on the volume manager (mdadm, LVM) for the same purpose.
- Compression and deduplication
- The file system compresses data before writing it and, in some systems, detects and eliminates duplicate data. Compression reduces the storage footprint; deduplication reduces it further when many files share the same contents. ZFS and Btrfs provide compression as a first-class feature; deduplication is available in ZFS and (with caveats) in Btrfs.
The trends are not universal, and the modern file systems implement them to different degrees. ext4 is a conservative modern file system: it uses extents and checksums but keeps journaling and relies on external tools for snapshots and RAID. XFS is a scalable modern file system: it uses B-trees and extents and is designed for large file systems and parallel workloads, but it does not provide snapshots or integrated RAID. Btrfs and ZFS are the most aggressive: they use copy-on-write, B-trees, checksums, snapshots, and integrated RAID, and they are designed as complete storage stacks rather than as file systems layered on top of a volume manager.
4.2 The workloads that drive the design
The modern file systems are designed for a set of workloads that the classical file systems handle poorly. The workloads include:
- Large file systems. A file system of tens of terabytes, with hundreds of millions of files, is common on servers and storage arrays. The classical file systems' linear scans and fixed-size metadata structures do not scale to these sizes.
- Many small files. A source code repository, a mail spool, a container image, or a build cache can contain millions of small files. The directory's lookup cost (Lesson 10.4) and the metadata overhead are the bottlenecks.
- Large files. A database, a virtual machine image, or a media file can be hundreds of gigabytes. The allocation method (Lesson 10.5) and the metadata overhead are the bottlenecks.
- Write-heavy workloads. A database, a log collector, or a build system writes continuously. The journaling or copy-on-write mechanism (Lesson 10.6) determines the write throughput.
- Data integrity. A storage system that holds important data must detect corruption and, if possible, recover from it. The checksums and the redundancy (RAID, mirrors) determine the system's integrity.
- Snapshots and versioning. A backup system, a testing environment, or a version control system needs point-in-time views of the data. The file system's snapshot support determines whether the views are cheap or expensive.
The workloads conflict with one another: a design that optimizes for many small files may be poor for large files, and a design that optimizes for write throughput may sacrifice integrity. The modern file systems make different choices about which workloads to optimize for, and the choices are the source of their differences.
4.3 ext4
ext4 is the fourth generation of the Extended File System, the file system that grew out of the original Unix File System and the Fast File System. It was introduced in 2008 as the successor to ext3, and it is the default file system on most Linux distributions. ext4's design is conservative: it keeps the classical structures (the inode table, the block bitmaps, the journal) and extends them with modern features.
ext4's principal features are:
- Extents. ext4 replaces the classical indirect-block scheme (Lesson 10.5) with extents. A file's inode holds up to four extents directly, and a larger file uses an extent tree — a B-tree of extents — rooted in the inode. The extent tree allows ext4 to describe a large, fragmented file with a few levels of metadata, which is far more efficient than the classical indirect blocks.
- HTree directories. ext4 uses the HTree (Lesson 10.4) for its directories, so a directory with millions of entries can be searched in a few block reads. The HTree is a B-tree-shaped hash table, and it is enabled by default on new file systems.
- Journaling. ext4 uses the JBD2 journaling layer (Lesson 10.6) with the ordered mode as its default. The journal is inode 8 of the file system.
- Metadata checksums. ext4 computes a checksum for every metadata block (the superblock, the inode table, the bitmaps, the extent tree blocks, and the directory blocks). The checksums detect corruption that the journal cannot, and they are enabled by default on new file systems.
- Multiblock allocation and delayed allocation. ext4's allocator groups contiguous block requests into a single allocation, and it delays the allocation until the data is flushed. The two techniques allow ext4 to allocate larger contiguous extents and to reduce fragmentation.
- Online resizing. ext4 can grow a mounted file system, and (since Linux 5.1) it can shrink one offline. The feature is important for virtual machine images and for storage arrays that grow over time.
- Nanosecond timestamps and large file support. ext4 supports timestamps with nanosecond resolution and file sizes up to 16 TB (with 4 KB blocks). The classical ext2 and ext3 supported only second resolution and 2 TB.
ext4's advantages are its maturity, its compatibility, and its balance. It is the most widely deployed Linux file system, and its on-disk format is stable enough that a file system created by one Linux kernel can be read by another. Its features are sufficient for most workloads: extents handle large files, HTrees handle large directories, journaling handles crashes, and checksums handle corruption.
ext4's limitations are its lack of snapshots and integrated RAID. The file system does not provide a point-in-time view of its state, so a backup must either quiesce the file system or rely on an external tool (LVM snapshots, which are block-level and do not understand the file system's structures). ext4 also does not manage multiple devices: it uses the volume manager (mdadm, LVM) for RAID, and its allocation policy is not aware of the devices' geometry. The limitations are the reason Btrfs and ZFS exist: they provide the features that ext4 lacks, at the cost of a more complex design.
4.4 XFS
XFS is a high-performance file system that was developed by Silicon Graphics in the early 1990s for its IRIX workstations and servers. It was ported to Linux in 2001 and is now a standard Linux file system, particularly for large file systems and for workloads with many parallel operations. XFS's design is built around scalability: it was designed from the beginning for large file systems, large files, and many concurrent operations.
XFS's principal features are:
- Allocation groups. XFS divides the device into allocation groups, each with its own inode table, free-space B+trees, and metadata. The allocation groups are independent, so operations in different groups can proceed in parallel, and the file system's metadata does not become a bottleneck as the file system grows. The allocation groups are XFS's answer to the Fast File System's block groups (Lesson 10.5), scaled up for large systems.
- B+tree metadata. XFS organizes all of its metadata — the directory entries, the extent lists, the free-space information — as B+trees. The B+trees give XFS O(log n) lookups and efficient range queries, and they allow the file system to scale to very large sizes without degrading.
- Extents. XFS uses extents for all file data, with a B+tree of extents for large files. The extents are stored in the inode for small files (the inode holds up to a few extents directly) and in the extent B+tree for large ones.
- Delayed allocation. XFS delays the allocation of a file's blocks until the data is flushed, so it can allocate larger contiguous extents and reduce fragmentation. The technique is similar to ext4's and is one of the reasons XFS achieves high write throughput.
- Journaling. XFS journals its metadata (it does not journal data), and its journal is a circular log. The journaling is efficient because XFS's metadata is already structured as a small number of B+tree updates.
- Online defragmentation and growth. XFS can defragment a mounted file system, and it can grow a mounted file system. The features are important for long-running systems that accumulate fragmentation.
- Metadata checksums. XFS computes checksums for its metadata blocks (the superblock, the inode table, the B+tree blocks, and the free-space structures). The checksums detect corruption, and they are enabled by default on new file systems.
XFS's advantages are its scalability and its performance for parallel workloads. It handles large file systems (up to 8 EB in theory, tens of petabytes in practice) and large files (up to 8 EB) with consistent performance, and its allocation groups allow many operations to proceed in parallel. It is the file system of choice for large servers, media servers, and storage arrays.
XFS's limitations are its lack of snapshots and integrated RAID (like ext4, it relies on external tools), its inability to shrink a file system (XFS can grow but not shrink), and its complexity. The allocation groups and the B+trees make the file system's metadata more complex than ext4's, and the complexity is reflected in the file system's tools and in the administrator's learning curve. The lack of snapshots is the reason some administrators choose Btrfs or ZFS for workloads that need them, even though XFS is faster for the workloads that do not.
4.5 Btrfs
Btrfs (the B-tree File System) is a modern file system that was developed by Oracle in 2007 and is now maintained by the Linux community. It was designed as a response to the limitations of ext4 and XFS: it provides snapshots, checksums, integrated RAID, and pooling as first-class features, and it is designed to be a complete storage stack rather than a file system layered on top of a volume manager.
Btrfs's design is built around copy-on-write (Lesson 10.6). The file system never overwrites a block in place: when a block is modified, the new version is written to a new location, and the block's parent is updated to point to the new version. The update propagates up the tree of metadata until the superblock's root pointer is updated atomically. The result is that Btrfs is always consistent, and the consistency comes without a journal.
Btrfs's principal features are:
- Copy-on-write. The file system's fundamental design. Every block — metadata and data — is written to a new location, and the tree's root pointer is updated atomically. The result is crash consistency without a journal, and the basis for snapshots and clones.
- Snapshots and subvolumes. A subvolume is an independent file tree within the file system, and a snapshot is a copy of a subvolume's root pointer. Because the snapshot shares the subvolume's data (the data is copy-on-write), the snapshot is cheap to create and takes no space until the subvolume or the snapshot is modified. The feature is the basis for backup and versioning workflows.
- Checksums. Btrfs computes a CRC-32C checksum for every data and metadata block. The checksums detect corruption, and the file system's tree structure allows it to verify that a block's contents are consistent with its checksum. The checksums are the basis for Btrfs's integrity guarantees.
- Integrated RAID. Btrfs manages multiple devices directly, with profiles that specify how the data is spread and mirrored. The profiles include single (no redundancy), RAID 0 (striping), RAID 1 (mirroring), RAID 10 (striping plus mirroring), and RAID 5/6 (parity). The integration means that the file system knows which blocks are redundant, so it can recover from a corrupted block by reading its replica.
- Compression. Btrfs compresses data before writing it, with the zlib, LZO, and Zstandard algorithms. The compression reduces the storage footprint, and it is transparent to applications.
- Deduplication. Btrfs can detect duplicate data and eliminate it (the feature is available but is not enabled by default, because it is memory-intensive).
- Online resizing, defragmentation, and scrub. Btrfs can grow and shrink a mounted file system, defragment a file or a subvolume, and scrub its data to verify the checksums and repair corruption from a replica.
Btrfs's advantages are its feature set: it provides snapshots, checksums, integrated RAID, compression, and pooling in a single file system, and its copy-on-write design makes the features natural rather than bolted on. It is the file system of choice for workloads that need snapshots (backup, testing, versioning) and for systems that want the storage stack to be a single component rather than a collection of tools.
Btrfs's limitations are its maturity and its performance. The file system has been in development for over fifteen years, but its RAID 5/6 support has had stability problems, and its performance for some workloads (particularly small files and databases) is lower than ext4's or XFS's. The copy-on-write design causes write amplification (a single logical write can cause several physical writes as the tree is updated), and the file system's allocator can fragment over time, particularly for databases and virtual machine images. The limitations are the reason Btrfs is not the default on most Linux distributions, even though its feature set is the most complete.
4.6 ZFS
ZFS is a file system and volume manager that was developed by Sun Microsystems in 2001 for its Solaris operating system. It was designed as a response to the complexity of the storage stack — the layers of file system, volume manager, and RAID controller — and its goal was to combine them into a single, coherent system. ZFS is now available on Linux (through the OpenZFS project), FreeBSD, and other systems, and it is widely used in storage servers and network-attached storage.
ZFS's design is built around two ideas: pooled storage and end-to-end integrity.
Pooled storage. ZFS does not present the administrator with a file system on top of a volume. Instead, the administrator creates a storage pool from a set of devices, and the pool's capacity is shared among the file systems (called datasets) that are created within it. A dataset's size is not fixed in advance: it can grow or shrink as the pool's free space changes, and the pool's free space is shared among all the datasets. The design eliminates the classical problem of a file system running out of space while another file system on the same device has free space.
End-to-end integrity. ZFS computes a checksum for every block — metadata and data — and stores the checksum in the block's parent rather than in the block itself. The arrangement means that the file system can verify a block's integrity without trusting the block's contents, and it can recover from corruption if a replica exists. The checksums are computed end-to-end: the file system verifies them when it reads a block, and it can verify them again when it scrubs the pool. The design is the most thorough integrity model of the modern file systems.
ZFS's principal features are:
- Pooled storage. A storage pool aggregates the devices, and datasets share the pool's capacity. The pool's redundancy is configured with RAID-Z (a RAID 5-like scheme with variable stripe width) or with mirrors.
- Copy-on-write. ZFS never overwrites a block in place; every modification writes a new block and updates the tree's root pointer. The result is crash consistency without a journal.
- Checksums. Every block has a checksum, stored in its parent. The checksums detect corruption, and the redundancy allows recovery.
- Snapshots and clones. A snapshot is a read-only point-in-time view of a dataset, and a clone is a writable copy of a snapshot. Both are cheap because the data is copy-on-write.
- Compression and deduplication. ZFS compresses data with the LZJB, gzip, or Zstandard algorithms, and it can deduplicate data (the feature is memory-intensive and is not enabled by default).
- Send and receive. ZFS can send a snapshot to another system and receive it there, which is the basis for replication and backup workflows. The feature is one of ZFS's most popular, because it allows a consistent snapshot to be transferred without quiescing the file system.
- ARC and L2ARC. ZFS's cache is the Adaptive Replacement Cache (ARC), which balances recency and frequency, and the L2ARC is a second-level cache on a separate device (typically an SSD). The caches improve the file system's read performance.
ZFS's advantages are its integrity model and its feature set. It is the most thorough of the modern file systems in its corruption detection and recovery, and its pooled storage, snapshots, and send/receive make it an excellent choice for storage servers and for backup systems. Its disadvantages are its memory requirements (the ARC needs several gigabytes of RAM to be effective), its licensing (the CDDL license is incompatible with the GPL, which is why ZFS is not in the mainline Linux kernel), and its performance for some workloads. The file system is not a general-purpose choice for a laptop or a desktop; it is a choice for a server that can devote the resources to it.
4.7 Flash-specific file systems: F2FS
The modern file systems described so far were designed for hard disks, whose characteristics are rotating platters, seek times, and in-place updates. Solid- state drives (SSDs) have different characteristics: they have no moving parts, their access time is uniform, and their flash memory cannot be updated in place — a block must be erased before it can be rewritten, and the erase operation works on a larger unit than the write operation. The mismatch between the file system's assumptions and the device's characteristics causes problems: in-place updates trigger the flash translation layer's read-modify-erase-write cycle, which is slow and reduces the device's lifetime.
F2FS (the Flash-Friendly File System) is a file system that was designed specifically for flash storage. It was developed by Samsung and is now in the mainline Linux kernel. Its design reflects the flash device's characteristics:
- Log-structured updates. F2FS writes updates sequentially to free regions rather than overwriting blocks in place. The log-structured approach matches the flash device's write-once, erase-many model: it turns random writes into sequential writes, which the device's flash translation layer handles more efficiently and with less write amplification.
- Clean and dirty segments. F2FS divides the device into segments, and it tracks which segments are clean (contain only valid data) and which are dirty (contain a mix of valid and invalid data). The cleaner process reclaims the dirty segments by copying their valid data to clean segments and erasing the dirty ones. The design minimizes the number of erases.
- Multi-head logging. F2FS maintains several logs (for hot, warm, and cold data) and writes each type of data to its own log. The separation keeps data with similar update frequencies together, which reduces the cleaner's work and improves the device's lifetime.
- Adaptive logging. F2FS adjusts its logging strategy to the device's characteristics, using the device's reported erase-block size and other parameters. The adaptation allows the file system to work well on a range of devices, from small embedded flash to large SSDs.
- Checksums and roll-forward recovery. F2FS computes checksums for its metadata and uses a roll-forward recovery mechanism that replays the log after a crash. The mechanism is simpler than journaling because the log-structured design already records the updates in order.
F2FS's advantages are its write performance and its device lifetime. By writing sequentially and minimizing erases, it achieves higher write throughput and longer device life than a general-purpose file system on the same hardware. Its disadvantages are its relative immaturity and its narrower applicability: it is optimized for flash storage, and its performance on hard disks (if it is used there at all) is not competitive with ext4's or XFS's. F2FS is the file system of choice for smartphones, embedded devices, and servers with flash-heavy workloads.
F2FS is not the only flash-specific file system;
others include JFFS2 and
UBIFS (for raw flash memory without
a flash translation layer) and the flash-friendly
modes of the general-purpose file systems (ext4's
discard option, XFS's
discard option, and the
fstrim command, which tell the device
which blocks are free so the device can reclaim
them). The general-purpose file systems can be used
on SSDs, but their performance and device lifetime
are lower than F2FS's because their designs assume
in-place updates.
4.8 Comparing the modern file systems
The following table summarizes the modern file systems' features. The table is a guide, not a substitute for the detailed descriptions in the preceding sections; each file system's suitability depends on the workload, and the table's entries are simplifications.
| Feature | ext4 | XFS | Btrfs | ZFS | F2FS |
|---|---|---|---|---|---|
| Allocation | Extents | Extents + B+tree | Extents + B-tree | Extents + tree | Log-structured |
| Directory | HTree | B+tree | B-tree | Tree | Hash / tree |
| Consistency | Journal (JBD2) | Journal | Copy-on-write | Copy-on-write | Roll-forward |
| Metadata checksums | Yes | Yes | Yes | Yes | Yes |
| Data checksums | No | No | Yes | Yes | No |
| Snapshots | External (LVM) | External (LVM) | Yes | Yes | No |
| Integrated RAID | No (mdadm/LVM) | No (mdadm/LVM) | Yes | Yes (RAID-Z) | No |
| Compression | No | No | Yes | Yes | No |
| Deduplication | No | No | Yes (optional) | Yes (optional) | No |
| Online grow | Yes | Yes | Yes | Yes | Yes |
| Online shrink | Offline | No | Yes | No | No |
| Maturity | Very high | High | Medium | High | Medium |
The table shows the trade-offs. ext4 and XFS are mature, conservative file systems: they use journaling and rely on external tools for snapshots and RAID, and they prioritize stability and performance over feature completeness. Btrfs and ZFS are aggressive, feature-complete file systems: they use copy-on-write and provide snapshots, checksums, and integrated RAID, and they prioritize feature completeness and integrity over the simplicity of the classical designs. F2FS is a specialized file system: it is optimized for flash storage and makes no claim to be a general-purpose choice.
The choice among the file systems is a matter of the
workload and the administrator's priorities. A
general-purpose server can use ext4 or XFS; a
storage server that needs snapshots and integrity
can use Btrfs or ZFS; a smartphone or an embedded
device can use F2FS. The choice is not permanent —
a file system can be migrated, and the modern tools
(rsync, btrfs send,
zfs send) make the migration
straightforward — but it is consequential, and the
administrator should make it deliberately rather
than by default.
4.9 Choosing a file system
The choice of a file system is a decision with several dimensions. The following questions frame the decision:
- What is the workload? A file system for a database, a media server, a build farm, a container host, and a backup server have different requirements. The workload's characteristics — file sizes, access patterns, write volume, read volume — determine which file system's optimizations matter.
- What is the scale? A file system for a laptop's 500 GB SSD and a file system for a server's 100 TB array have different scaling requirements. The classical file systems' metadata structures do not scale to the largest sizes; the modern B-tree-based file systems do.
- What integrity is required? A file system that holds important data must detect corruption and, if possible, recover from it. The checksums and the redundancy determine the system's integrity. ext4 and XFS checksum their metadata; Btrfs and ZFS checksum data as well.
- Are snapshots required? A backup system, a testing environment, or a version control system needs point-in-time views. Btrfs and ZFS provide them as first-class features; ext4 and XFS require external tools.
- What is the device? A hard disk, an SSD, and a network-attached storage array have different characteristics. F2FS is optimized for flash; the other file systems are optimized for hard disks but work on SSDs.
- What is the administrator's expertise? A file system's complexity is a cost. Btrfs and ZFS have more features and more knobs; ext4 and XFS have fewer. The choice should reflect the administrator's ability to manage the system.
The decision is not purely technical. The file system's licensing, its support in the operating system, and the community's experience with it are also factors. ZFS's CDDL license is incompatible with the GPL, which is why it is not in the mainline Linux kernel; Btrfs's RAID 5/6 support has had stability problems, which is why some administrators avoid it for critical data. The technical factors are necessary but not sufficient; the practical factors matter too.
4.10 The future of file systems
The file systems' future is being shaped by several trends:
- Flash and non-volatile memory. The shift from hard disks to SSDs and to non-volatile memory (NVDIMM, Intel Optane) is changing the file systems' assumptions. The flash-specific file systems (F2FS) and the flash-friendly modes of the general-purpose file systems address the current generation; the next generation of storage-class memory will require new designs.
- Scale. File systems are growing, and the metadata structures are growing with them. The B-tree-based designs (XFS, Btrfs, ZFS) scale to the largest sizes; the classical designs (ext2, ext3) do not. The trend is toward the B-tree and toward the pooled storage model.
- Integrity. The recognition that disks lie — that a disk can report a successful write that never reached the platter — is driving the adoption of checksums and end-to-end integrity. ZFS's model is the most thorough; Btrfs is close; ext4 and XFS checksum metadata only. The trend is toward checksumming everything.
- Snapshots and versioning. The recognition that snapshots are useful — for backup, for testing, for versioning — is driving their adoption. Btrfs and ZFS provide them as first-class features; the other file systems provide them through external tools. The trend is toward snapshots as a standard feature.
- Compression and deduplication. The recognition that storage is finite and that data is often compressible is driving the adoption of compression and deduplication. ZFS and Btrfs provide them; the other file systems do not. The trend is toward compression as a standard feature.
- Distributed and cloud file systems. The shift to cloud storage is driving the development of distributed file systems (Ceph, GlusterFS, HDFS) and of file systems that run on top of object stores. The trend is toward file systems that span multiple devices and multiple sites, and that tolerate the failure of an entire site.
The file system is not a solved problem. The classical designs (contiguous, linked, indexed) are still the foundation, and the modern designs (extents, B-trees, copy-on-write) are the current state of the art, but the trends suggest that the next generation will be shaped by the new storage technologies and by the new workloads they enable. The file system's design space is large, and the choices are consequential; the modern file systems' variety is evidence that no single design is best for all workloads.
4.11 Common misconceptions
"All modern file systems are the same."
The modern file systems share design trends (extents, B-trees, checksums) but differ in their strategies and their feature sets. ext4 uses journaling; Btrfs and ZFS use copy-on-write. ext4 checksums metadata only; ZFS checksums data too. ext4 relies on external tools for snapshots; Btrfs and ZFS provide them. The differences matter for specific workloads.
"Newer is always better."
The newest file systems (Btrfs, ZFS) have the most features, but they are not the best choice for every workload. A database server may perform better on XFS than on Btrfs because XFS's in-place updates avoid the copy-on-write amplification. A laptop may be better served by ext4 than by ZFS because ZFS's memory requirements are high. The choice should reflect the workload, not the file system's age.
"Checksums replace RAID."
Checksums and RAID serve different purposes. Checksums detect corruption; RAID provides redundancy that allows recovery. A checksum without a replica can detect corruption but cannot repair it. ZFS and Btrfs combine the two: the checksums detect the corruption, and the redundancy (mirrors, RAID-Z) allows the file system to recover from a replica.
"Snapshots are copies of the data."
In a copy-on-write file system, a snapshot is a copy of the root pointer, not of the data. The snapshot shares the data with the original until one of them is modified, at which point the modified data is written to a new location and the two diverge. The snapshot is cheap to create and takes no space until the data diverges.
"F2FS is only for smartphones."
F2FS was designed for flash storage, and smartphones were an early use case, but it is also used on servers with flash-heavy workloads and on embedded devices. Its log-structured design gives it higher write throughput and longer device life than the general-purpose file systems on the same hardware.
"ZFS's memory requirements are a bug."
ZFS's ARC cache is a feature, not a bug: it improves the file system's read performance by caching frequently accessed data. The cache's size is tunable, and the file system works with less memory than the recommended amount, but its performance degrades. The memory requirement is a consequence of the design, not a defect.
"The file system choice is permanent."
A file system can be migrated, and the modern
tools make the migration straightforward.
rsync copies the data from one file
system to another; btrfs send and
zfs send transfer snapshots; the
volume manager can migrate a logical volume
between file systems. The choice is consequential,
but it is not permanent.
"A file system's features are free."
Every feature has a cost. Checksums cost CPU time. Compression costs CPU time and adds latency. Snapshots cost metadata and can cause fragmentation. Copy-on-write causes write amplification. The features are worth their cost for the workloads that need them, but they are not free, and enabling a feature that a workload does not need can hurt performance.
05 Worked example
The following example compares the modern file systems on a concrete workload, shows the commands that administrators use to inspect each system, and demonstrates the trade-offs in practice.
Choosing a file system for a workload
Consider a workload with the following characteristics:
- Data: 50 TB of documents, images, and videos, with a mix of large files (videos, 1–10 GB each) and small files (documents, 10–100 KB each).
- Access: mostly read-heavy, with periodic bulk writes from a content-management system.
- Backup: nightly backups, with snapshots taken every hour.
- Integrity: the data must be protected against corruption; a corrupted video must be detectable, and if possible recoverable.
- Hardware: a storage server with eight 10 TB hard disks and two 1 TB SSDs for caching.
The workload's requirements point to a file system with snapshots, checksums, and integrated RAID. The candidates are Btrfs and ZFS.
Comparing Btrfs and ZFS for the workload
| Requirement | Btrfs | ZFS |
|---|---|---|
| Snapshots | Yes, subvolumes and snapshots | Yes, datasets and snapshots |
| Checksums (data) | Yes, CRC-32C | Yes, multiple algorithms |
| Integrated RAID | Yes, profiles including RAID 1, RAID 10 | Yes, RAID-Z and mirrors |
| Compression | Yes, zlib/LZO/Zstd | Yes, LZJB/gzip/Zstd |
| Send/receive | Yes, btrfs send |
Yes, zfs send |
| Large file performance | Good | Good |
| Small file performance | Moderate | Moderate |
| Memory requirement | Moderate | High (ARC) |
| Licensing | GPL (in mainline Linux) | CDDL (not in mainline Linux) |
Both file systems satisfy the workload's requirements. The choice between them depends on the administrator's priorities and on the environment:
- Btrfs is in the mainline Linux kernel, so it is available on any Linux distribution without additional modules. Its memory requirement is moderate, and its snapshots and send/receive are mature. Its RAID 5/6 support has had stability problems, but its RAID 1 and RAID 10 profiles are stable, and the workload's redundancy can use them.
- ZFS has a more thorough integrity model (it checksums data and stores the checksums in the parent block, so it can detect corruption that a block-level checksum cannot). Its send/receive is mature, and its RAID-Z is stable. Its memory requirement is high, and its licensing means it must be installed as an out-of-tree module on Linux.
For this workload, the recommendation is Btrfs with RAID 1 or RAID 10, for three reasons: it is in the mainline kernel (so it is simpler to install and maintain), its memory requirement is lower, and its RAID 1/10 profiles are stable. ZFS would be the choice if the integrity requirement were stronger (for example, if the data were subject to silent corruption from a faulty controller) or if the environment already used ZFS.
Inspecting a file system's configuration
The Linux tools let an administrator inspect each file system's configuration. The following commands show the features and parameters of a file system on a live system.
# Identify the file system types on the system
df -T
lsblk -f
# Inspect an ext4 file system
sudo tune2fs -l /dev/sda1 2>/dev/null | grep -iE 'features|journal|block count'
# Inspect an XFS file system
sudo xfs_info /dev/sdb1 2>/dev/null
# Inspect a Btrfs file system
sudo btrfs filesystem show /dev/sdc1
sudo btrfs filesystem df /mnt/btrfs
sudo btrfs subvolume list /mnt/btrfs
# Inspect a ZFS pool (if ZFS is installed)
sudo zpool status
sudo zfs list
sudo zfs get all tank/data
The commands' outputs show the file systems'
features and parameters. The
tune2fs output shows ext4's feature
flags (including has_journal,
extent, dir_index, and
metadata_csum). The
xfs_info output shows XFS's block
size, allocation group count, and other
parameters. The btrfs commands show
Btrfs's devices, its space usage, and its
subvolumes. The zpool and
zfs commands show ZFS's pool
configuration and its datasets' properties.
Demonstrating a snapshot
The following commands demonstrate Btrfs's snapshot feature. The snapshot is created instantly and takes no space until the data diverges.
# Create a Btrfs file system (in a file for the demo)
dd if=/dev/zero of=/tmp/btrfs-demo.img bs=1M count=500
sudo mkfs.btrfs /tmp/btrfs-demo.img
sudo mkdir -p /mnt/btrfs-demo
sudo mount -o loop /tmp/btrfs-demo.img /mnt/btrfs-demo
# Create some data
echo "version 1" > /mnt/btrfs-demo/file.txt
sudo mkdir /mnt/btrfs-demo/data
for i in $(seq 1 100); do
echo "data $i" > /mnt/btrfs-demo/data/file$i.txt
done
# Take a snapshot
sudo btrfs subvolume snapshot /mnt/btrfs-demo /mnt/btrfs-demo/snap1
# Verify the snapshot's contents
ls /mnt/btrfs-demo/snap1/
cat /mnt/btrfs-demo/snap1/file.txt
# Modify the original
echo "version 2" > /mnt/btrfs-demo/file.txt
# Compare the original and the snapshot
cat /mnt/btrfs-demo/file.txt
cat /mnt/btrfs-demo/snap1/file.txt
# Show the space usage (the snapshot shares the data)
sudo btrfs filesystem df /mnt/btrfs-demo
The snapshot is a point-in-time view of the file
system. The original's file.txt
contains "version 2", and the snapshot's contains
"version 1". The snapshot's space usage is small
because it shares the unchanged data with the
original.
Demonstrating checksums
The following commands demonstrate Btrfs's checksum feature. The scrub process verifies the checksums and reports any corruption.
# Run a scrub on the Btrfs file system
sudo btrfs scrub start /mnt/btrfs-demo
sudo btrfs scrub status /mnt/btrfs-demo
# The scrub reads every block and verifies its checksum.
# If a block is corrupt, the scrub reports it and, if a
# replica exists, repairs it from the replica.The scrub's output shows the number of blocks verified, the number of errors, and the number of repairs. On a healthy file system, the error count is zero; on a file system with a corrupt block, the scrub reports the corruption and, if a replica exists, repairs the block.
06 Interactive activity
Activity · explore the modern file systems on a live system
The goal of this activity is to use the Linux command line to inspect the modern file systems' configurations, to create and test the file systems' features, and to compare their behaviour. Work through the steps in your course VM.
-
Identify the file systems on your
system.
Use
dfandlsblkto list the file systems and their types.
What file systems are in use on your system? What are their types? Which one is the root file system? Write down what you find.# List the mounted file systems and their types df -T # List the block devices and their file systems lsblk -f # For each file system, note its type (ext4, xfs, btrfs, etc.) # and its mount point. -
Inspect an ext4 file system.
Use
tune2fsto examine the file system's features and parameters.
Which features are enabled? Is the journal enabled? Is the directory indexing (HTree) enabled? Are metadata checksums enabled? Write down what you find.# Show the file system's features and parameters sudo tune2fs -l /dev/sda1 2>/dev/null | grep -iE 'features|journal|block count|inode count' # Show the file system's journal parameters sudo tune2fs -l /dev/sda1 2>/dev/null | grep -i journal # Show the directory indexing feature sudo tune2fs -l /dev/sda1 2>/dev/null | grep -i dir_index -
Inspect an XFS file system (if
available).
If your VM has an XFS file system (or if you can
create one in a file), inspect its parameters.
What are the file system's parameters? How many allocation groups does it have? What is the block size? How does the output compare to ext4's?# Create an XFS file system in a file dd if=/dev/zero of=/tmp/xfs.img bs=1M count=500 sudo mkfs.xfs /tmp/xfs.img sudo mkdir -p /mnt/xfs sudo mount -o loop /tmp/xfs.img /mnt/xfs # Inspect its parameters sudo xfs_info /mnt/xfs # The output shows the block size, the allocation group # count, the inode size, and other parameters. -
Create a Btrfs file system and test its
features.
Create a Btrfs file system in a file and test its
snapshots, checksums, and compression.
Does the snapshot capture the original state? Does the scrub find any errors? What does the scrub's output tell you about the file system's integrity?# Create a Btrfs file system in a file dd if=/dev/zero of=/tmp/btrfs.img bs=1M count=500 sudo mkfs.btrfs /tmp/btrfs.img sudo mkdir -p /mnt/btrfs sudo mount -o loop /tmp/btrfs.img /mnt/btrfs # Create some data echo "test data" > /mnt/btrfs/file.txt sudo mkdir /mnt/btrfs/data for i in $(seq 1 50); do echo "data $i" > /mnt/btrfs/data/file$i.txt done # Take a snapshot sudo btrfs subvolume snapshot /mnt/btrfs /mnt/btrfs/snap1 # Modify the original echo "modified" > /mnt/btrfs/file.txt # Compare the original and the snapshot cat /mnt/btrfs/file.txt cat /mnt/btrfs/snap1/file.txt # Run a scrub to verify the checksums sudo btrfs scrub start /mnt/btrfs sudo btrfs scrub status /mnt/btrfs -
Compare the file systems' performance.
Create the same workload on ext4, XFS, and Btrfs
(each in a file), and compare the results.
Which file system is fastest for the large file? Which is fastest for the many small files? Do the results match your expectations? Explain the differences in terms of the file systems' design.# Create a small file system of each type for fs in ext4 xfs btrfs; do dd if=/dev/zero of=/tmp/$fs-test.img bs=1M count=500 2>/dev/null sudo mkfs.$fs /tmp/$fs-test.img 2>/dev/null sudo mkdir -p /mnt/$fs-test sudo mount -o loop /tmp/$fs-test.img /mnt/$fs-test done # Create a large file on each for fs in ext4 xfs btrfs; do echo "=== $fs ===" time dd if=/dev/zero of=/mnt/$fs-test/large.bin bs=1M count=300 2>/dev/null done # Create many small files on each for fs in ext4 xfs btrfs; do echo "=== $fs ===" time (for i in $(seq 1 1000); do echo "test" > /mnt/$fs-test/small$i.txt done) done # Clean up for fs in ext4 xfs btrfs; do sudo umount /mnt/$fs-test rm /tmp/$fs-test.img done -
Examine the file systems' space
usage.
Use each file system's tools to examine its space
usage and its metadata overhead.
How does each file system report its space usage? What is the metadata overhead for each? How does the overhead compare across the file systems?# For ext4 sudo tune2fs -l /dev/sda1 2>/dev/null | grep -iE 'block count|free block|inode count|free inode' # For XFS sudo xfs_info /mnt/xfs 2>/dev/null sudo xfs_db -r -c 'freesp -s' /dev/sdb1 2>/dev/null # For Btrfs sudo btrfs filesystem df /mnt/btrfs sudo btrfs filesystem usage /mnt/btrfs -
Test compression (Btrfs).
If your Btrfs file system supports compression,
test its effect on a compressible file.
How much space does the compressible file use? How much does the incompressible file use? What does the difference tell you about compression's effectiveness?# Mount with compression enabled sudo mount -o remount,compress=zstd /mnt/btrfs # Create a compressible file dd if=/dev/zero of=/mnt/btrfs/zeros.bin bs=1M count=100 # Create an incompressible file dd if=/dev/urandom of=/mnt/btrfs/random.bin bs=1M count=100 # Compare the space usage sudo btrfs filesystem df /mnt/btrfs ls -lh /mnt/btrfs/zeros.bin /mnt/btrfs/random.bin # The zeros.bin file should use much less space than its # apparent size; the random.bin file should use its full # size. -
Read the man pages.
Read the man pages that document the modern file
systems.
For each, write a sentence describing its main contribution to your understanding of the modern file systems. Theman 5 ext4 man 5 xfs man 5 btrfs man 8 mkfs.ext4 man 8 mkfs.xfs man 8 mkfs.btrfs man 8 btrfs man 8 xfs_infoman 5pages document the file systems' features and mount options; theman 8pages document the tools that create and manage them.
Reflect: the modern file systems are the accumulation of five decades of research and engineering. Each one is a response to the limitations of its predecessors, and each one makes different trade-offs. The choice among them is a decision that administrators make, often by default, and the decision has consequences for performance, integrity, and manageability. Which of the modern file systems' features matter most for the workloads you care about? What would you sacrifice — performance, simplicity, or features — to get the ones you need? How would you explain the trade-offs to someone who assumes that all file systems are the same? What does the variety of the modern file systems tell you about the file system's design space?
07 Knowledge check
Check your understanding
Question 1
What makes a file system "modern"? List the design trends that the modern file systems share, and explain why each trend matters.
Show answer
Question 2
Compare ext4 and XFS. What are each file system's design goals, principal features, and limitations?
Show answer
Question 3
Describe Btrfs's copy-on-write design and explain how it provides snapshots, checksums, and integrated RAID. What are the design's limitations?
Show answer
Question 4
Describe ZFS's pooled storage and end-to-end integrity model. How does ZFS differ from the other modern file systems, and what are the trade-offs of its design?
Show answer
Question 5
Describe F2FS and explain how it addresses the characteristics of flash storage. Why is a flash-specific file system needed, and what trade-offs does it make?
Show answer
08 Unit discussion
Discussion prompt
This lesson completes Unit 10, and it is worth stepping back to see the arc of the unit. The unit began with the file as a named sequence of bytes and the directory as a mapping from names to inodes. It then examined the metadata (Lesson 10.2), the inode (Lesson 10.3), the directory's internal structure (Lesson 10.4), the allocation of a file's blocks (Lesson 10.5), and the journal that keeps the metadata consistent (Lesson 10.6). This lesson put the pieces back together and showed how the modern file systems — ext4, XFS, Btrfs, ZFS, and F2FS — combine the concepts.
The arc reveals a pattern: each concept has a classical form and a modern form. The file is classical; the extent is modern. The linear-list directory is classical; the B-tree directory is modern. The single-block index is classical; the extent is modern. The journal is classical; the copy-on-write tree is modern. The pattern is not accidental: the modern forms are responses to the workloads that the classical forms handle poorly, and the workloads have grown with the storage. The file systems of the 1970s handled megabytes; the file systems of the 2020s handle petabytes. The design space has expanded accordingly.
The pattern suggests a question about the future. The modern file systems are built on the classical concepts — the inode, the directory, the block, the extent — but the concepts themselves are being challenged. Object stores (S3, Ceph) replace the file abstraction with a flat namespace of objects. Content-addressable storage (Git, IPFS) replaces the name with a hash. Key-value stores (RocksDB, LevelDB) replace the file with a sorted map. Each of these alternatives trades the file system's interface for a different one, and each is better suited to some workloads.
Are the file system's classical concepts — the file, the directory, the inode, the block — still the right abstractions for the storage of the future? What would a storage system look like if it were designed today, with the benefit of fifty years of hindsight and the demands of cloud, flash, and distributed workloads? What should be kept, and what should be replaced? Post your response to the Unit 10 discussion forum and reply to at least two classmates. Supports CLO1, CLO5, CLO7, and CLO8.
09 Practice exercise
This ungraded exercise consolidates Unit 10 and prepares you for Unit 11. Aim to spend 90–120 minutes on it.
- Compare the modern file systems. Write a short essay (400–500 words) comparing ext4, XFS, Btrfs, and ZFS. Your essay should address: (a) each file system's design goals; (b) its approach to allocation, directories, and crash consistency; (c) its feature set (checksums, snapshots, integrated RAID, compression); (d) its maturity and its limitations; (e) the workloads for which each is best suited. Conclude with a recommendation for a general-purpose server and a recommendation for a storage server, with justifications.
-
Test the file systems' features.
Create a small file system of each type (ext4,
XFS, Btrfs) in a file, and test the features that
each supports.
Record the results. Which file system is fastest for large files? Which for small files? How does the Btrfs snapshot compare to the other file systems' capabilities?# Create the file systems for fs in ext4 xfs btrfs; do dd if=/dev/zero of=/tmp/$fs.img bs=1M count=500 2>/dev/null sudo mkfs.$fs /tmp/$fs.img 2>/dev/null sudo mkdir -p /mnt/$fs sudo mount -o loop /tmp/$fs.img /mnt/$fs done # Test: create a large file on each for fs in ext4 xfs btrfs; do echo "=== $fs: large file ===" time dd if=/dev/zero of=/mnt/$fs/large.bin bs=1M count=300 2>/dev/null done # Test: create many small files on each for fs in ext4 xfs btrfs; do echo "=== $fs: small files ===" time (for i in $(seq 1 1000); do echo "test" > /mnt/$fs/small$i.txt done) done # Test: snapshot (Btrfs only) sudo btrfs subvolume snapshot /mnt/btrfs /mnt/btrfs/snap1 sudo btrfs subvolume list /mnt/btrfs # Clean up for fs in ext4 xfs btrfs; do sudo umount /mnt/$fs rm /tmp/$fs.img done -
Investigate a file system's metadata
overhead.
For each file system, compute the metadata
overhead by comparing the file system's capacity
with the space available for file data.
What is the metadata overhead for each? How does it compare? Which file system has the lowest overhead, and which the highest? Explain the differences in terms of the file systems' design.# For ext4 sudo tune2fs -l /dev/sda1 2>/dev/null | grep -iE 'block count|inode count' # For XFS sudo xfs_info /mnt/xfs 2>/dev/null # For Btrfs sudo btrfs filesystem df /mnt/btrfs sudo btrfs filesystem usage /mnt/btrfs -
Test compression.
On a Btrfs file system with compression enabled,
create a compressible file and an incompressible
file, and compare their space usage.
How much space does the compressible file use? How much does the incompressible file use? What compression ratio does the compressible file achieve? What does the result tell you about compression's applicability?# Mount Btrfs with compression sudo mount -o compress=zstd /mnt/btrfs # Create a compressible file dd if=/dev/zero of=/mnt/btrfs/zeros.bin bs=1M count=100 # Create an incompressible file dd if=/dev/urandom of=/mnt/btrfs/random.bin bs=1M count=100 # Compare the space usage sudo btrfs filesystem df /mnt/btrfs ls -lh /mnt/btrfs/zeros.bin /mnt/btrfs/random.bin # The apparent size is 100 MB for both, but the actual # space usage differs. -
Investigate the file systems' integrity
features.
For each file system that supports checksums,
determine what is checksummed (metadata only, or
data too) and how the checksums can be verified.
What does each file system checksum? How can the checksums be verified? What happens if a checksum fails and a replica exists? What happens if no replica exists?# For ext4, check the metadata_csum feature sudo tune2fs -l /dev/sda1 2>/dev/null | grep -i csum # For Btrfs, run a scrub sudo btrfs scrub start /mnt/btrfs sudo btrfs scrub status /mnt/btrfs # For ZFS (if available), run a scrub sudo zpool scrub tank sudo zpool status tank -
Design a storage system.
A university is building a storage system for its
research data. The system will hold 500 TB of
data, including large datasets (genomics,
climate models) and many small files (source
code, configuration files). The data is critical
and must be protected against corruption. The
researchers need snapshots for their experiments
and for versioning. The system has 24 hard disks
and 4 SSDs.
- Which file system would you choose, and why?
- How would you configure the storage (RAID, pooling)?
- How would you use snapshots and versioning?
- How would you verify the data's integrity?
- How would you handle the system's growth over time?
- Reflect on the unit. In your own words, summarize the arc of Unit 10: how the file, the directory, the inode, the allocation, and the journal fit together, and how the modern file systems combine them. Then identify one concept from the unit that changed your understanding of file systems, and explain why. Finally, identify one question about file systems that the unit did not answer, and explain what you would need to learn to answer it.
10 Summary
- A modern file system is one whose design reflects the last three decades of research and engineering and whose feature set addresses the workloads of the present. The modern file systems share design trends: extents, B-tree metadata, checksums, journaling or copy-on-write, snapshots, integrated RAID, and compression.
- ext4 is the conservative modern file system. It uses extents, HTree directories, the JBD2 journal (ordered mode by default), metadata checksums, multiblock and delayed allocation, and online resizing. Its advantages are its maturity, compatibility, and balance; its limitations are its lack of snapshots and integrated RAID.
- XFS is the scalable modern file system. It uses allocation groups, B+tree metadata, extents, delayed allocation, journaling, and metadata checksums. Its advantages are its scalability and its performance for parallel workloads; its limitations are its lack of snapshots and integrated RAID, its inability to shrink, and its complexity.
- Btrfs is the feature-complete modern file system. It uses copy-on-write, B-trees, checksums, snapshots and subvolumes, integrated RAID, compression, and deduplication. Its advantages are its feature set; its limitations are its maturity (particularly RAID 5/6) and its performance for some workloads (due to write amplification and fragmentation).
- ZFS is the integrity-focused modern file system. It uses pooled storage, copy-on-write, checksums stored in parent blocks, snapshots and clones, integrated RAID-Z, and send/receive. Its advantages are its integrity model and its feature set; its limitations are its memory requirements, its licensing, and its performance for some workloads.
- F2FS is the flash-specific file system. It uses log-structured updates, clean and dirty segments, multi-head and adaptive logging, and roll-forward recovery. Its advantages are its write performance and its device lifetime on flash storage; its limitations are its narrower applicability and its relative immaturity.
- The choice among the file systems depends on the workload, the scale, the integrity requirement, the need for snapshots, the device, and the administrator's expertise. The decision is consequential but not permanent: the file systems can be migrated with the modern tools.
- The file systems' future is being shaped by flash and non-volatile memory, by scale, by the recognition that disks lie (driving checksums and end-to-end integrity), by the adoption of snapshots, by compression and deduplication, and by distributed and cloud storage. The file system's design space is large, and no single design is best for all workloads.
Unit 10 complete — looking ahead to Unit 11
This lesson completes Unit 10. The unit has presented the file system from the file and the directory (Lessons 10.1–10.4) through the allocation of blocks (Lesson 10.5) and the journal that keeps the metadata consistent (Lesson 10.6) to the modern file systems that combine the concepts (Lesson 10.7). Unit 11, I/O and Storage Management, continues the story below the file system: it presents the I/O hardware (disks, SSDs, and their interfaces), the interrupt and DMA mechanisms that move data between the device and memory, the device drivers that translate the file system's requests into the device's commands, the disk scheduling algorithms that order the requests, the RAID levels that provide redundancy, and the SSD architecture that the flash-specific file systems (like F2FS) are designed for. The two units together cover the storage stack from the application's file operations down to the device's physical behaviour.
11 References
- Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapters 14, 15, and 16.
-
Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C.
Operating Systems: Three Easy Pieces, Chapters 40,
41, and 42. Available online at
ostep.org. - Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 4.
- Mathur, A., Cao, M., Bhattacharya, S., Dilger, A., Tomas, A., & Vivier, L. The New Ext3 Directory Index. Ottawa Linux Symposium, 2007.
- Rodeh, O., Bacik, J., & Mason, C. BTRFS: The Linux B-Tree Filesystem. ACM Transactions on Storage, 2013.
- Bonwick, J., & Moore, B. ZFS: The Last Word in File Systems. Sun Microsystems, 2007.
- Lee, C., Sim, D., Hwang, J., & Cho, S. F2FS: A New File System for Flash Storage. USENIX FAST, 2015.
- Sweeney, A., Doucette, D., Hu, W., Anderson, C., Nishimoto, M., & Peck, G. Scalability in the XFS File System. USENIX Annual Technical Conference, 1996.
- McKusick, M. K., Joy, W. N., Leffler, S. J., & Fabry, R. S. A Fast File System for UNIX. ACM Transactions on Computer Systems, 1984.
- Tweedie, S. C. Journaling the Linux ext2fs File System. USENIX Annual Technical Conference, 1998.
- Prabhakaran, V., Arpaci-Dusseau, A. C., & Arpaci-Dusseau, R. H. Analysis and Evolution of Journaling File Systems. USENIX Annual Technical Conference, 2005.
- Rosenblum, M., & Ousterhout, J. K. The Design and Implementation of a Log-Structured File System. ACM Transactions on Computer Systems, 1992.
-
Linux man-pages:
man 5 ext4,man 5 xfs,man 5 btrfs,man 5 f2fs,man 8 mkfs.ext4,man 8 mkfs.xfs,man 8 mkfs.btrfs,man 8 mkfs.f2fs,man 8 btrfs,man 8 xfs_info,man 8 tune2fs,man 1 df,man 1 lsblk.