• 上周学习了<Strata: A cross media file system>(SOSP 17' ). 想着记录&总结一下

SOSP（操作系统原理大会）自1967年创办以来，两年一届，已经有50个年头了。从1969年的UNIX系统到21世纪初的MapReduce、BigTable、GFS，系统领域一系列最有影响的工作都是发表在SOSP以及与它隔年举行的兄弟会议OSDI上。

• 这篇论文也是非常有水平，较为完善的一篇论文.

overview

如今文件系统存在的一些问题：

• 内核对每个操作都有干预：NVM很快，内核是瓶颈所在(如图所示，一次写操作，写到NVM设备延时远远小于进入内核态所带来的开销)

  IO latency.png

• NVM、SSD、HDD各有优劣，三者都是可持久化设备，如下图所示，NVM的读写延迟最低，但目前的技术中容量较小，价格较高；SSD处于中间位置；HDD发展最久，读写延迟由于机械开销而最高，但能满足大容量，且价格最低。想要具有高性能且低成本，必须混合利用多种设备类型。

  现有的介质对比.png

• 目前的基于块设备的传统文件系统，例如EXT4、F2FS，都是将数据缓存在DRAM中，只有在必须时才写入设备（fsync）--一致性无法保障。

Motivation

1. 存储介质的多样化为混合文件系统提供了可能。
2. 应用程序对文件系统的依赖和需求（一致性）：当系统崩溃时能快速恢复到一致性状态，块设备（SSD/HDD）太慢，如果log/journal存放在NVM上可以加速恢复
3. 当前文件系统几乎只是针对某一种特定的存储介质：NOVA for NVM、F2FS for SSD、Ext4 for HDD；多种存储介质并存时存在写入放大的问题，因为不同存储介质特性不同；当前文件系统大多只是一个block store interface，没有丰富的语义（针对应用程序）

Strata设计目标

• 快速写。Strata支持快速随机小写
• 高效同步（sync）过程。Strata在同步的时候尽量减少性能损失。
• 减少写入放大。合理安排数据迁移的粒度。
• 高并发性。Strata支持多个线程并发logging
• 统一的接口(Unified Interface)。Strata的基本架构类似于LSM tree。Strata首先将log同步写到NVM（write-efficient），然后周期性（异步）的digest到Kernel FS（per-file extent tree，read-optimized）。
• log在用户态，digest在内核中实现。
• 根据SSD/HDD特性，在（Kernel FS）数据迁移的时候都是顺序写，并选择合适的粒度。

• 硬件辅助保护机制。保证绕过内核时的安全。

  
  strata.png

LibFS

LibFS.png

• 内核利用Intel的libpmem直接访问NVM的一块空间（mmap方式直接访问）。在用户态实现一个库， 用于拦截系统调用，兼容POSIX接口。
  优点：

1. 用户态的库直接拦截系统调用，避免了进入内核态的开销，在应用程序这一层实现file I/O.
2. 提供快速同步的持久化。 可以绕过page cache，直接写NVM，消除了内存复制的写入延迟。
3. Log的一致性。Strata将一次持久化粒度定义为一个transaction。
4. 快速读。LibFS将（SSD/HDD）数据缓存在DRAM中，NVM中数据不用缓存。

KernelFS

KernelFS.png

Kernel FS主要负责在内核中管理可能存在于任何存储介质层的共享数据。为了做到这一点，Kernel FS将LibFS中的log digest进来，并转化为per-file extent tree的形式。

• 当log的大小超过一定的阈值（在Strata中为30%），Strata就会通过后台线程（异步）的执行digest。为了减少digest的开销，Strata在digest之前会合并消除一些冗余的log。
• 内核在后台异步digest日志，并在digest完成后回复LibFS。完成后，通过重置每个日志的header的有效位，LibFS可以安全地回收日志条目。
• 为了充分利用各个层次存储介质，Strata在Kernel FS中维持了两个LRU list，一个用于NVM-SSD之间的数据迁移，一个用于SSD-HDD之间数据迁移。
• 和digest类似，数据迁移也是以log-structured的结构方式。为了减少开销，写入到SSD是以erase为单元（百兆级别），写入到HDD是以瓦磁盘方式（GB级别）。

Sharing (leases)

• 为了能够提供更丰富的（共享）语义，对每一个文件Strata支持一个线程写、多个线程读的共享方式。有点类似于锁机制。

Evaluation

环境

• 2x Intel Xeon E5-2640 CPU, 64 GB DRAM, 400 GB NVMe SSD, 1 TB HDD
• Ubuntu 16.04 LTS, Linux kernel 4.8.12
• 模拟NVM: 4GB的DRAM来模拟

对比

• NVM文件系统

1. PMFS
2. NOVA
3. EXT4-DAX

• SSD文件系统

1. F2FS

• HDD文件系统

1. EXT4

Filebench测试

• 使用Varmail负载以及Fileserver负载
• 配置：10000files/32KB(avg for varmail) & 128KB(avg for fileserver)/16KB appends/ 读写比1:1(for varmail) & 2:1(for fileserver)/两种工作负载都以1MB的粒度读取和写入数据

• 测试结果：

  
  strata-filebench测试结果.png

Data Migration

• 为了测试Strata使用多个存储设备时的性能，我们将Fileserver配置为1MB，1000files。在这种情况下，工作集一开始在NVM中运行，但随后会digest到SSD和HDD。

• 测试结果：

  
  data migration.png

总结

• 这篇论文很能发现问题，首先发现现有的基于单一介质的文件系统并不能同时满足大容量，高性能，性价比高的需求，所以提出了多种介质混合的想法；第二，通过发现用户态和内核态切换开销所占比例过大，设计了LibFS和KernelFS两者功能各司其职又相互协作的文件系统，其中LibFS拦截了系统调用，自己实现了用户态的库，通过mmap( )的方法直接写到NVM上，然后再在内核态中进一步的digest进去，这一做法十分新颖且高效。
• 实验部分也做的很完善，在本文中我并没有完全写完它的实验部分，感兴趣的可自己看看。实验结果也说明了Strata确实实现了高吞吐量，低延迟的性能。
• Source code is available at strata github.