OPIMQ: Order Preserving IO stack for Multi-Queue Block Device
summary
OPIMQ enforces storage order across host and multi‑queue devices by tagging each IO with stream and app IDs and by four concrete mechanisms: Epoch Pinning, Dual-Stream Write, order‑preserving mapping table updates, and sibling‑aware delayed mapping. Implemented in Linux and evaluated with EXT4 on a 40‑core server and a Samsung 980 Pro, it marks dual‑stream writes with two stream/epoch pairs, delays L2P updates until both constraints hold, and reports 2.9×/2.8×/2.9× speedups on Filebench varmail, dbench, sysbench and a 1.1% FTL translation penalty.
AI-written summary · about
chapters (14)
- 0:00OPIMQ introduction
- 1:44Storage order in multi-queue
- 3:54Limitations of order-preserving
- 4:56Streams and apps in I/O
- 6:40Guaranteeing inter-stream order
- 7:02OPIMQ design overview
- 8:28App pinning to prevent split
- 9:11Dual-stream writes for order
- 10:37Sibling-aware delayed mapping
- 11:41Evaluation setup and metrics
- 12:26Fsync latency in OPEXT4
- 13:11Macrobenchmark results
- 13:54OPFTL overhead analysis
- 14:15Conclusion and availability
related talks
42mUnderstanding the Linux Block Layer-From Single Queue to Multi-Queue Architecture
38mUh-oh, It's I/O Ordering!
45mLinux Storage Stack Explained
24mOptimizing Storage Performance for 4–5 Million IOPs
45mData Placement in Linux: Evolving Block and File I/O
30mQEMU-Storage-Daemon and libblkio: Exploring New Shores for the QE...
19mI/O Passthru: Upstreaming a flexible and efficient I/O Path in Linux
18mDm-qcow2: qcow2 as Device-mapper Block Device