Skip to content

Commit aece235

Browse files
authored
Merge pull request #6 from metaspace/null
null_blk: Add description and benchmark results
2 parents cc01ae2 + a01f13c commit aece235

8 files changed

+12022
-0
lines changed

SUMMARY.md

+1
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,7 @@
2222
## Users
2323

2424
- [NVMe Driver](NVMe-driver.md)
25+
- [Null Block Driver](Null-Block-Driver.md)
2526
- [Android Binder Driver](Android-Binder-Driver.md)
2627

2728
# Links

src/Null-Block-Driver.md

+91
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
2+
# Null Block Driver
3+
4+
The Rust null block driver `rnull` is an effort to implement a drop in
5+
replacement for `null_blk` in Rust.
6+
7+
A null block driver is a good opportunity to evaluate Rust bindings for the
8+
block layer. It is a small and simple driver and thus should be simple to reason
9+
about. Further, the null block driver is not usually deployed in production
10+
environments. Thus, it should be fairly straight forward to review, and any
11+
potential issues are not going to bring down any production workloads.
12+
13+
Being small and simple, the null block driver is a good place to introduce the
14+
Linux kernel storage community to Rust. This will help prepare the community for
15+
future Rust projects and facilitate a better maintenance process for these
16+
projects.
17+
18+
[Statistics](https://lore.kernel.org/all/[email protected]/) from the
19+
commit log of the [C `null_blk`
20+
driver](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/block/null_blk?h=v6.1)
21+
([before
22+
move](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/block/null_blk_main.c?h=v6.1&id=ea17fd354ca8afd3e8962a77236b1a9a59262fdd))
23+
show that the C null block driver has had a significant amount of memory safety
24+
related problems in the past. 41% of fixes merged for the C null block driver
25+
are fixes for memory safety issues. This makes the null block driver a good
26+
candidate for rewriting in Rust.
27+
28+
The driver is implemented entirely in safe Rust, with all unsafe code fully
29+
contained in the abstractions that wrap the C APIs.
30+
31+
## Features
32+
33+
Implemented features:
34+
35+
- `blk-mq` support
36+
- Direct completion of IO
37+
- Read and write requests
38+
- Optional memory backing
39+
40+
Features available in the C `null_blk` driver that are currently not implemented
41+
in this work:
42+
43+
- Bio-based submission
44+
- NUMA support
45+
- Block size configuration
46+
- Multiple devices
47+
- Dynamic device creation/destruction
48+
- Soft-IRQ and timer mode
49+
- Queue depth configuration
50+
- Queue count configuration
51+
- Discard operation support
52+
- Cache emulation
53+
- Bandwidth throttling
54+
- Per node hctx
55+
- IO scheduler configuration
56+
- Blocking submission mode
57+
- Shared tags configuration (for >1 device)
58+
- Zoned storage support
59+
- Bad block simulation
60+
- Poll queues
61+
62+
## Resources
63+
64+
- [Patches for 6.6](https://github.com/metaspace/linux/tree/null_blk-next-for-6.6)
65+
- [Original RFC Patches](https://github.com/metaspace/linux/tree/null_block-RFC)
66+
- [Mailing List Post](https://lore.kernel.org/all/[email protected]/)
67+
68+
# Performance
69+
70+
## Setup
71+
72+
- 12th Gen Intel(R) Core(TM) i5-12600
73+
- 32 GB DRAM
74+
- 1x INTEL MEMPEK1W016GA (PCIe 3.0 x2)
75+
- Debian Bullseye userspace
76+
77+
## Results
78+
79+
In most cases there is less than 2% difference between the Rust and C drivers.
80+
81+
![](./rnull/read-iops.svg)
82+
![](./rnull/write-iops.svg)
83+
![](./rnull/randread-iops.svg)
84+
![](./rnull/randwrite-iops.svg)
85+
![](./rnull/readwrite-iops.svg)
86+
![](./rnull/randrw-iops.svg)
87+
88+
# Contact
89+
90+
Please contact Andreas Hindborg through
91+
[Zulip](Contact.md#zulip-chat).

0 commit comments

Comments
 (0)