XRP：使用EBPF优化内核存储设备功能

随着访问时间可达微秒级别的NVMe存储的出现，Linux内核中控制存储设备的软件所带来的的开销变得尤为明显。

上图表示了不同存储设备软件和硬件访问开销的占比，表中为不同组件在NVM-2中各个软件组件的breakdown。可以看到，对于NVMe设备来说，软件层的开销甚至可能会使访问时间翻倍。为了解决上述问题，本篇论文提出了XRP，用来执行用户自定义的存储功能来减少内核所带来的开销。

挑战

设计主要面临两个挑战，

• 地址空间转换与安全性问题：XRP需要直接与NVMe驱动进行交互，然而驱动层面面临的是设备上的物理区块和偏移，缺乏上层文件系统中的一些语义。如果允许开发者自行访问物理区块的话，这样可能会带来安全性问题。
• 并发访问和缓存问题：一些写操作可能不会立刻存入设备中，而是停留在页表缓存（page cache）中，XRP无法预知这种行为。除此之外，一些写操作会修改文件布局的数据结构（如下一个区块的指针），此时若有并发读取数据的行为则会导致数据读取错误。尽管可以通过加锁来解决相关问题，但是锁的开销很大。

作者观察到许多存储在设备上的数据结构是相对稳定的，要么不更新（LSM树），要么不会频繁更新（B树）。并且在存储引擎中，索引都存在少量大型文件中，并且每个索引不会跨越多个文件。这个观察引申出了下述设计理念，

• 同一时间只处理一个文件：XRP仅在单个文件上使用链式重新提交。

• 稳定数据结构：XRP目标的数据结构的布局在一段时间内不会改变。

• 用户管理缓存：XRP不干预page cache，所以当区块在page cache中使用XRP可能会导致错误。由于一些存储引擎也实现了用户空间缓存，这项限制也是合理的。

设计与实现

• I/O请求重提交

• XRP放置一个BPF hook在NVMe中断处理函数中，以翻译应用层的数据结构，并将定位好的硬件信息直接向设备发送请求。这个过程主要包含：1. BPF Hook的设置；2. BPF验证器；3. 元数据摘要；4. 读取请求的重发。

• 同步的限制

• BPF只支持受限制的自旋锁同步机制。用户可以使用BPF的操作来自定义自旋锁，同时也可以使用RCU机制。

• 与Linux调度器交互

• 进程调度：作者发现当多个进程共享同一个core的时候，即便所有的I/O请求都是用户空间发出的，像Optane SSD这种微秒级的设备也会干扰Linux的CFS。尽管XRP的链式中断加剧了这个问题，但作者觉得这个问题并不是eBPF特有的，别的因素也可能导致类似的问题，因此作者把解决该问题作为未来工作。
• I/O调度：XRP绕过了Linux的I/O调度器，但仍会受到NVMe设备上调度器的限制。

实现案例

• 作者完成了两种具体的实现来验证XRP，包括BPF-KV数据库（基于B树索引的KV数据库）和WiredTiger存储引擎（MongoDB的后端引擎）。详细内容参考原论文。