结合Seastar 的网络消息层实现读写路径上的零（最小）拷贝。
对于目标 1、2，面向 NVMe 的设计，笔者认为主要是指当前的 NVMe 设备是可以使用用户态驱动的，即可以不通过系统内核，使用 Polling 模型能够明显降低 IO 延时。
同时对于 NVMe 设备来说，由于其 erase-before-write 特性带来的 GC 问题需要被高效解决，理论上通过 discard 作为一种 hint 机制可以让上层软件启发底层闪存去安排 GC，但实际上大部分闪存设备的 discard 实现的并不理想，因此需要上层软件的介入。
对于目标 3、4，是从如何降低 CPU 的角度去考虑底层存储设计的，如上文中也提到对于高性能的分布式存储，CPU 会成为系统瓶颈，如何提高 CPU 的有效使用率是一个重点考虑的问题。
目标 3 中采用 run-to-completion 的方式能够避免线程切换和锁的开销，从而有效提高 CPU 的使用率，Intel 曾经发布报告说明，在 Block Size 为 4KB 的情况下，单线程利用 SPDK 能够提供高达 1039 万 IOPS，充分说明了使用单线程异步编程的方式能够有效提升 CPU 的使用率。
而目标 4 则需要充分结合网络模型，一致性协议等，实现零拷贝，来降低在模块中内存拷贝次数。
基于 SeaStore 的设计目标，具体的设计方案中主要考虑了通过 segment 的数据布局来实现的 NMVE 设备的 GC 优化，以及上层如果控制 GC 时的相关处理，同时在文档中也提到了用 B-tree 的方式实现元数据的存储，而没有采用类似 bluestore 中使用 RocksDB 来存储元数据的方式。
但是笔者认为，这个设计对于实现的难度可能比较高，当前的 rados 不仅仅是存储数据还有大量的元数据存储的功能。如 OMAP 和 XATTR，这些小的 KV 信息实际如果采用新写一个 B-tree 的方式进行存储，那相当于需要实现一个专有的小型 KV 数据库，这个功能实现难度会非常大，而类似直接使用简单的 B-tree 存储元数据就会落入类型 XFS 等文件系统存储元数据的困境，不能存储大量 xattr 的问题。
上文中只是简单的描述的 Ceph 对下一代存储引擎的设计构思，如果想等到具体的开源来实现估计还需要个 3 到 5 年的开发周期。
而我们对高性能分布式存储的需求又非常热切，所以深信服存储团队就独立设计了一个全新的存储引擎来满足高性能分布式存储的需求。
下面我们简单介绍深信服企业级分布式存储 EDS 团队在高性能本地存储的实践之路。
PFStore 设计与实现
PFStore（Phoenix Fast Store）是 EDS 团队自研的基于 SPDK 的用户态本地存储引擎，它的核心架构如下图所示。
在系统中主要有数据管理和元数据管理两大核心模块，下面介绍一下两大核心模块的职责和技术特点：
