Evaluating File System Reliability on Solid State Drives
summary
Built a device-mapper injector that intercepts and corrupts or drops block I/O and runs over a thousand injected fault cases against ext4, Btrfs and F2FS, reporting that 16% unrecoverable results leave filesystems unmountable or fsck-unfixable. ext4 shows strong detection and recovery via sanity checks and fsck, Btrfs detects many corruptions but SSD-default metadata de-duplication causes major data loss, and F2FS consistently fails to detect or recover write I/O errors.
AI-written summary · about
chapters (11)
- 0:00Start
- 0:24Introduction & Motivation
- 1:22Research Questions & Methodology
- 1:49SSD Faults and their Manifestation
- 3:38How to test the resiliency of file systems against SSD faults?
- 4:39Targeted Error Injection
- 5:13How do file systems detect and recover from errors?
- 7:07Results - Overview (2/2)
- 8:08ext4 Results
- 10:06Btrfs Corruption Scenario
- 13:50Thank you! Questions?
related talks
23mCan Applications Recover from fsync Failures?
01h 12mRedundancy does not imply fault tolerance
41mFinding the Best Block Filesystem for Your Embedded Linux System
34mEnhancing Data Integrity in Linux
42mCan File Systems Survive in Data-centric World?
39mDon’t eat my data - 30+ years of storage war stories
40mLinux Storage System Bottleneck for eMMC/UFS
30mHybrid XFS: Idea to Exabytes in 12 Months