Octopus FS 论文阅读 （一）

Octopus 论文阅读

Octopus: an RDMA-enabled Distributed Persistent Memory File System 论文阅读

摘要

1. 共享内存池减少memory copy
2. self-identified RPC
3. 分布式事务机制保证一致性

Introduction

In conclusion, the strict isolation between the file system and network layers makes distributed file systems too heavy to exploit the benefits of emerging high-speed hardware.

data management

• shared persistent memory pool
• client-active mode to rebalance server and network loads

metadata management

• self-identified RPC（using RDMA）

consistency

• 一种新的分布式事务机制

Design

Octopus在以下方面进行了创新

1. 高吞吐的数据IO：shared persistent memory pool for 高带宽，client-active for 高吞吐。
2. 低延迟的metadata访问：self-inentified RPC and collect-dispatch 事务来处理一致性问题。

Overview

一些要点：

1. Octopus没有中心化的metadata server，metadata分别存储在多个server中；
2. 一个文件的metadata和data block在一个server上，但是它的父目录以及子目录的文件可能就在其他的server上；
3. shared persistent memory pool的意思就是把所有的server中的非易失内存都看作一块非易失内存，因此并不存在文件数据的拷贝，即只需要metadata的更新即可；
4. metadata是server私有的，data blocks是全局公用的；
5. 新增了一个message pool用来暂时存放metadata RPC时的msg；
6. 通过RPC访问metadata，RDMA原语访问data

（文中一直在说目前的分布式文件系统是覆盖在本地文件系统上的，需要去找一个分布式文件系统验证一下，比如glusterFS。）

接下来分别进行介绍。

高吞吐的IO流

shared persistent memory pool

以一次文件复制为例，对于一次文件复制操作，传统的分布式文件系统需要7次memory copy。

FS -> server page cache -> server user buffer -> server kernel buffer(mbuf) -> server NIC buffer -> client NIC buffer -> client kernel buffer -> client user buffer。

对于本地非易失文件系统实现的direct access(DAX)机制，也只能bypass page cache，copy次数只能从7变成6.

因此Octopus将全部的非易失内存注册为ibv_reg_mr，即支持通过RDMA进行远程的direct access，省去了server端的大量memory copy，即：

FS -> server NIC buffer -> client NIC buffer -> client kernel buffer -> client user buffer

从7变成4.

client-active

以一次client读文件为例。

传统的 server-active 模式是server找到相关的数据，将数据作为payload发送给client。

而 client-active 模式是server找到相关的数据后，将数据的metadata发送给client（metadata的相关操作通过self-identified RPC实现），client自己去server的内存中通过RDMA READ读取数据。

核心思想是牺牲网络性能来降低server的负载。

接下来很自然会想到如果多个request请求一个文件怎么办？Octopus使用文件级别的读写锁来处理这个问题。server持有锁（GCC原子指令），client读写完成后发出释放信号（RDMA原语）。

一个问题：如果释放锁的RDMA原语由于某种原因丢失了，或者server没收到，那这个server是否会一直持有这个锁？造成一直不可写？

不懂QAQ：Note that serializability between GCC and RDMA atomic primitives is not guaranteed due to lack of atomicity between the CPU and the NIC.

low latency metadata access

Octopus通过RDMA write verb和原子操作完成metadata access（self-identified RPC以及分布式事务等）

self-identified metadata RPC

中心思想是使用write_with_imm来代替RDMA one-sided和two-sided操作实现RPC，具体来说是client的imm field中加上node_id和offset（client recv buffer的offset）。因为write_with_imm可以在到达对端时立即通知对端，相比来说write并不会立即通知对端，需要对端一直轮询message buffer。

相当于client使用write_with_imm告知server自己的node_id以及recv buffer的offset，server解析完imm之后就可以使用RDMA write来把需要的数据直接发送给client的recv buffer的相应位置。

collect-dispatch transaction

collect 所有的参与者的read write sets，在协商者中做出对应的更新，之后协商者把最后全部参与者需要commit的 write sets下发下去，这样因为不需要各个参与者的协商，所以过程得到了简化。

关于协商者和参与者的锁设计，使用了类似文件级别的读写锁（GCC and RDMA write），GCC加锁，RDMA write解锁，锁的是文件系统的log zone，用compare_and_swap命令。

总的来说，传统的分布式事务2PC需要2个RPC，collect-dispatch事务需要一个RPC（collect read write sets），两个RDMA write（一个dispatch write sets，另一个释放读写锁），因为RDMA write以及原语并不需要CPU参与，所以可以认为这个分布式事务是一个延迟更低，负载更小的分布式事务设计。

数据一致性

分别来说，Octopus的metadata一致性是通过在collect-dispatch事务中使用clflush保证的；目前的实现中没有保证文件数据的一致性。

相关资料

文件系统的原理-兰新宇
分布式系统事务