背景
最近研究NVME SSD 比较多，为了后面更有效地开展工作，计划近期梳理下NVME SSD在业界和学术界的最新方法和进展。
阅读的NVME SSD论文
NVME SSD IO堆栈的优化
NVMEDirect
改造NVME SSD的内核驱动中的数据面，提供读写open/write/close/read 等标准操作。也bypass了内核中通用快层。
亮点：根据不同应用场景，应用线程可以独享一个HW queue, 可以共享一个HW queue pair,也可以被多个HW queue 处理。
NVMEDirect on smart phone
http://csl.skku.edu/papers/tce17.pdf
亮点：对异步IO可以共享hardware queue pair; 对于同步IO 独享hardware queue pair；
PolarFS
阿里的分布式文件系统。
* Chunk: 10G.而非64MiB 为何这么大，减小metadata;
这样在FSSwitch 中就能够cache住；而且对meta data数据库的影响也不大。缺点：热点Chunk相对不容易迁移，好在ChunkServer数量多。类似CDS的Block
- Block: 64KB,逻辑地址到物理地址映射的最小单元。类似CDS的slice。一个Chunk只需要160K个Block， 地址饮食关系需要640KB。很高效。这样一个10T的盘，需要640M 内存，8个盘，也只需要5.1G内存。
上面阿里的Chunk/Block Size的设计决定了为何它们没有索引占用内存过多的问题。
- PolarSwitch
内存CDS的cds-agent。把计算节点对Chunk的读写请求路由到chunkServer. 同样，DBServer上也有一个LocalMetaCache, 及时从PolarControl同步信息，获取Leader节点信息。 -
ChunkServer
功能同百度的CDS。区别在于为了避免线程、核间的干扰，
阿里的一个存储节点上为每个NVME SSD盘部署一个ChunkServer, 每个绑定一个固定的处理器核。也是append写，WAL写到3D Xpoint buffer; data然后写到Chunk 。 -
PolarController
类似百度CDS的master, 提供集群级别的元数据管理。
(1) keeping track of the membership and liveness of all ChunkServers
(2) maintaining the state of all volumes and chunk locations in metadata database.
(3) creating volumes and assigning chunks to ChunkServers.
(4) synchronizing metadata to Po- larSwitch using both push and pull methods.
(5) monitor- ing the latency/IOPS metrics of each volume and chunk, collecting trace data along the I/O path.
(6) scheduling inner-replicas and inter-replicas CRC checks periodically -
libpolar_filesystem
和PolarSwitch 直接交互，通过ring buffer：
libpfs 把请求塞到ring buffer; PolarSwitch不停地抽取request 去执行。这点和百度CDS的cds-agent不一样。 -
IO线程模型
写过程：主体同百度CDS的 write写过程；
读过程：只有 Leader服务于都请求。区别：需要一个额外的仲裁模块，来保证始终能读到最新的数据。In ChunkServer there is a submodule named IoSched- uler which is responsible to arbitrate the order of disk I/O operations issued by concurrent I/O requests to execute on the ChunkServer. IoScheduler guarantees that a read oper- ation can always retrieve the latest committed data
阿里通过polling 的线程模型来获取来做RDMA或者NVME的event, 逐一处理。由于IO线程之间没有共享数据，因此IO线程处理数据的时候都是无锁的。
问题：下面这句话没看懂，如何切换？为何需要切换？
“ChunkServer uses polling mode along with event-driven finite state machine as the concurrency model. The I/O thread keeps polling events from RDMA and NVMe queues, processing incoming requests in the same thread. When one or more asynchronous I/O operations are issued and other requests are needed to be handled, the I/O thread will pause processing current request and save the context into a state machine, then switch to process the next incoming event. Each I/O thread uses a dedicated core and uses separated RDMA and NVMe queue pairs. ” -
MulitRaft
相对百度CDS使用Raft的优点，MulitRaft 的主要优点包括：基于落在同一个复制组内，逻辑卷之间的数据允许并行执行applied/commited.
通过记录已经append但还没有commited 的entry的逻辑地址范围，可以预知逻辑地址是否和新来的请求的IO范围冲突。显然，冲突的就需要等；不冲突的就不需要等。
** 关于选主 (Leader Election)
引入了 pre-leader/real-leader, merge reading（LBB look behinde buffer）等方法，实现了
之前raft check leader 的语义。
** 关于追数据（Catch up）
&&
SSD 擦后写介质的优化
研究除了顺序写之外，是否还有更好的方式也可以充分发挥NVME SSD盘的性能。