论文学习：Ziggurat: A tiered File System for Non-Volatile Main Memories and Disks

Background

NVMM的出现相比于传统磁盘来说，具有更高的吞吐量和更低的延迟，极大地提高了存储性能，目前针对NVMM设计的文件系统利用持久内存的直接访问(DAX)功能绕过页面缓存层，并为用户应用程序提供对文件数据的直接访问。但NVMM成本比较高，因此需要SSD和HDD去提供更大的容量。基于此，本文提出了一种分层文件系统，管理异构的存储设备，并根据数据性能要求和应用程序未来的访问模式将数据放置到最合适的层。

Question

根据上述阐述，涉及到的问题包括：

数据的放置策略：由于NVMM的容量有限且DRAM扔具有比NVMM更好的性能，异步写的数据是不影响程序性能的，所以提出了以下数据放置策略：（将小的；同步更新的数据写入到NVMM，将大的异步更新的数据写入到DRAM中，后台写回disk）

因此，需要识别那些将写入的数据类型是怎样的，文中提出了两个预测器：

write size predictor
- 功能: 预测写入的数据是否是大的，且判断是否是稳定的（在同一地址范围内的未来写入可能也很大）
- 实现: 在每个write entry中都保留一个计数器，以指示写入大小是否既大又稳定。当Ziggurat重写旧的写条目时，它首先检查写入大小足够大，至少可以覆盖原始日志条目占用的面积的一半。如果是，Ziggurat将旧写条目的计数器值传递给新条目，并将其增加1。否则，它会将计数器重置为零。如果数字大于4(可调参数)，Ziggurat将写入分类为“大”。既大又异步的写入磁盘
synchronicity predictor
- 功能: 预测应用程序未来是否可能调用fsync
- 实现: 计算在两个对fsync的调用之间写入文件的数据块的数量。如果数字小于一个阈值(例如，在我们的实验中为1024)，则将其视为同步更新的文件。预测器以O_SYNC同步方式打开文件处理写入
其他问题：
- 同步写大小阈值：实验中将同步写大小阈值从4KB变化到1GB，结果表明性能对此阈值变化不敏感，平均吞吐量的标准差小于3%。通常，同步写入大小阈值应该比来自工作负载的同步写入操作的平均I/O大小略大一些
- 顺序写入计数器阈值：实验中将Ziggurat的顺序写计数器阈值从1更改到64，发现不同的顺序写计数器阈值对性能的影响很小，因为实验中的工作负载的特性是稳定的。当使用不稳定的访问模式运行工作负载时，用户应该平衡准确性和预测开销之间的权衡。

2. 数据的迁移策略：

迁移时间：基于应用程序的读写模式使用动态迁移阈值（基于整个文件系统的读写比从50%增加到90%）
迁移机制：估计文件数据的温度，将冷的文件数据迁移到disk
实现：根据文件的平均修改时间估计文件的温度，为识别一个文件中最冷的block，Ziggurat跟踪文件中每个block的修改时间。在每个CPU中维护一个冷列表，以文件的平均修改时间（通过文件中所有block进行计算）进行排序，迁移数据时，若最冷的文件修改时间超过30s，则视为冷文件，全部进行迁移，否则，迁移修改时间早于文件平均修改时间的block块
迁移方式：Basic Migration / Group Migration
- Basic Migration：将最冷的数据（一个文件中最冷的block）迁移到disks；迁移粒度为一个write entry。锁的粒度为一个write entry。在迁移过程中，若DRAM page cache 的使用率非常低（eg.50%），会在DRAM中创建副本，为未来的读操作。以write entry的粒度实现逆向迁移（disk-NVMM）针对以读为主的工作负载。
- Group Migration：避免细粒度的迁移和最大化disk顺序带宽。将小的随机写合并为大的顺序写。迁移粒度应该设置接近未来的I/O大小，以便应用程序使用顺序读取从disks提取数据。此外，它不应超过cpu缓存大小，以最大化从disks加载write entry的性能。
- File Log Migration：当NVMM利用很高时，定期扫描冷文件的日志，开始迁移。迁移时将live log 复制到DRAM中。

Evaluation

使用NVMM（模拟）+SSD（Optane SSD/NVMe SSD）
与以下文件系统做比较：

基于NVM的文件系统：NOVA、Strata、EXT4-DAX、XFS-DAX
基于disk的文件系统：EXT4-DJ（journal 保存在NVMM2GB的journal block device中）
XFS-ML（元数据日志记录设备是2GB的NVMM）

Microbenchmarks（Fio）
证明了访问局部性与读写吞吐量之间的关系

其中图例50/50表示50%的访问是50%的数据，以此值来控制访问的局部性；
Ziggurat-2表示NVMM的大小为2GB；
实验使用20个线程，每个线程对一个私有的文件执行4KB IO，所有的写都是同步写；
结论：随着局部性的增加，随机读的性能增加，读的开销主要来源于将冷的数据从disk加载到DRAM中，因此局部性越高，CPU缓存命中率越高，性能越好；不同局部性条件下Ziggurat的随机写入性能差异很小，由于所有的写入都是同步的4kb对齐写入，Ziggurat将这些写入引导到NVMM。Ziggurat-2利用per-cpu迁移线程并发迁移以保证迁移的效率。
Macrobenchmarks
使用Filebench中的工作负载：filesever、webproxy、varmail评估Ziggurat整体的性能。

图5为多个线程之间的比较，图6为单个线程；
结论：Webproxy以读为主，能充分利用page cache实现高的吞吐量；
在单线程下，对于varmail，Strata合并了许多临时性写性能最好，但由于读的性能差
不如Ziggurat.
Rocksdb
使用Rocksdb证明使用write-ahead logging更新键值存储的高性能。对Rocksdb的每次更新都会写入两个位置：内存中的数据结构，称为MemoryTable和文件系统中的write-ahead log。当MemoryTable的大小达到阈值时，Rocksdb将其写回磁盘并丢弃日志。

图7a和图7b，Ziggurat的随机插入和顺序插入的结果之间的差异是由于不对齐写入的read-modify-write。在随机插入工作负载中，数据库文件的旧数据块可能在磁盘上，特别是在NVMM大小较小的情况下。因此，从磁盘加载它们会带来很大的开销。但是，在顺序插入中，旧的数据块来自最近写入，可能在NVMM中的文件。因此，Ziggurat在顺序插入工作负载中实现了接近-NVMM的性能。
在顺序读取方面，Ziggurat-2比Ext-DJ和XFS-ML分别高出42.8%和47.5%。随着NVMM尺寸的增加，Ziggurat的性能逐渐提高。Ziggurat-64、Nova、EXT 4-DAX和XFS-DAX的读取吞吐量接近(6%以内)。
SQLite
使用SQLite分析不同logging机制的性能。利用Mobibench使用以下三种journaling模式测试SQLite的性能：Delete、Persist和WAL(write-ahead log)。

DELETE和PERSIST是回滚journaling模式。journaling文件在DELETE mode下，在每个事务结束时被删除。PERSIET mode放弃删除，而是用零覆盖日志头。WAL mode使用写前日志记录进行回滚日志记录。对于DELETE 和PERIST，journal文件要么是短暂的，要么是频繁更新的。因此，它们被Ziggurat的迁移分析器分类为热文件。因此，Ziggurat仅迁移数据库文件中的冷的部分，将journal文件留在NVMM中以吸收频繁更新。性能的提高得益于Ziggurat高的迁移效率。由于高效的迁移机制，Ziggurat可以快速清除NVMM中的空间，为即将到来的小的写做准备。因此，Ziggurat在所有配置中都保持接近-NVMM的性能。
在WAL模式下，有三种类型的文件：主数据库文件和每个数据库的两个临时文件：Wal和SHM。Wal文件是write-ahead log files，在键值插入期间是热的。SHM文件是共享内存文件，用作WAL文件的索引。SQLite通过mmap访问它们。ZIggurat将热数据保持在NVMM中，同时在后台将大的数据库文件冷的部分迁移到disks，对前端数据库的操作仅产生较小的开销。
MySQL
使用MySQL评估数据库吞吐量，实验运行20GB的数据集

Ziggurat的性能总是接近或优于Ext-DJ和XFS-ML。平均而言，Ziggurat-2的性能比基于磁盘的文件系统高出1%(OptanSSD)和19%(NVMe SSD)。During the transactions，Ziggurat负责管理NVMM的大部分小更新。由于事务需要在dram中处理，因此Ziggurat能够及时将数据块迁移到磁盘，以留出足够的NVMM空间接收新的写。因此，即使很小的NVMM都能保持接近与NVMM的性能。

Conclusion

ziggurat是一个跨NVMM和disk的分层文件系统。通过精确和轻量级的预测器来管理数据放置，以引导传入的文件写入最合适的层次，并提出了一种高效的迁移机制，它利用存储设备的不同特性来实现高迁移效率。性能介于基于disk构建的文件系统和基于NVMM构建的文件系统。