Modernizing File System through In-Storage Indexing
Talkat 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI '21) · 2021-07-14..07-16·
summary
KEVIN replaces the block interface with a host-side lightweight POSIX file system that maps files to inode-based keys (meta keys prefixed m, data keys prefixed d, 4KB sub-objects for large files) and an SSD that implements an LSM3 in-storage indexing variant plus transactional support so crash consistency needs no host journaling. Implemented on an FPGA with real NAND flash, the system is 10.8K LOC and reduces host I/O, showing 6.2× on metadata-intensive benchmarks and 68% throughput gains on realistic workloads.
AI-written summary · about
chapters (10)
- 0:00Intro
- 0:57Does the performance of a FS scale with faster SSDs? Performance evaluation on EXT4 using 5 SSDs with different performance
- 2:03Why does file system have to do such tasks?
- 2:38Prior studies - Extended block interface Extended block interface
- 3:09Prior studies - File interface File system interface
- 5:14File-to-KV mapping Map files/directories to two types of KV objects (meta & data objects)
- 8:17KV object indexing algorithm (Cont.)
- 10:25Transaction management Lightweight crash consistency with in-storage transaction support
- 11:27Objectives
- 12:52Conclusion Traditional file systems cannot exploit fast storage performance because of fundamental limitations of the block interface
related talks
33mSSDFS: Flash-friendly File System with Highly Minimized GC Activity, Diff-on-write, & Deduplication
17mINSIDER: Designing In-Storage Computing System for Emerging High-Performance Drive
38mEROFS, an Introduction and our Smartphone Practice
46mZMS a New Lightweight Storage System
17mEROFS: A Compression-friendly Readonly File System for Resource-scarce Devices
30mScalable Parallel Flash Firmware for Many-core Architectures
36mFrom Raw To Refined: The Evolution of Raw Flash Support in Linux
53mIntel ME: Flash File System Explained