Linux Storage Stack Explained
summary
Overview of how Linux turns file operations into block I/Os and where latency or throughput actually changes: VFS plus page cache produce BIOs, block layer and stackable devices (dm‑crypt, MD, LVM, DRBD) can be piled with little scheduling, then block‑mq maps per‑CPU software queues to hardware queues — e.g. a 6‑core CPU yields six software queues even if an NVMe has 16 HW queues. Covers ext3/4 and btrfs differences, direct I/O vs page cache, Linux iSCSI/NVMe targets and why multi‑queue was needed for flash.
AI-written summary · about
chapters (11)
- 0:00Welcome
- 3:13Secondary storage essentials
- 8:18User data storage needs
- 10:28Storage stack overview
- 15:30VFS layer explained
- 24:35Block filesystems and inodes
- 27:28Btrfs and ZFS
- 31:52Device mapper
- 36:53Multi-queue architecture
- 41:56Hardware queues performance
- 44:05Summary
related talks
42mUnderstanding the Linux Block Layer-From Single Queue to Multi-Queue Architecture
52mPeeling Back the Layers of Storage
15mRearchitecting Linux Storage Stack for µs Latency and High Throughput
32mUsing Linux Block Integrity in Building and Testing Storage Systems
48mRecent Changes in the Linux I/O Stack from a DBA’s Perspective
17mHow advancements in storage are triggering innovations in open-source and vice-versa
48mSoftware Defined Storage the Linux way
45mData Placement in Linux: Evolving Block and File I/O