跨存储介质文件系统

Strara：跨存储介质的文件系统

参考来源

1. SOSP 2017 论文Topics
   https://www.jianshu.com/p/128a49cebe28?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendationhttps://www.jianshu.com/p/128a49cebe28?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation
2. 论文学习：Strata: A cross media file system
   

作者介绍

• Youngjin Kwon,The University of Texas at Austin
  • 作者是来自德克萨斯大学奥斯汀分校（The University of Texas at Austin）的CS PHD Youngjin Kwon
  • 其导师是Prof. Emmett Witchel和 Prof. Simon Peter教师
  • Youngjin Kwon的主要研究兴趣是操作系统，包括文件系统、新兴存储和内存技术、系统安全技术、虚拟化。
• Henrique Fingler,The University of Texas at Austin
• Tyler Hunt,The University of Texas at Austin
• Simon Peter,The University of Texas at Austin
• Emmett Witchel,The University of Texas at Austin
• Thomas Anderson,University of Washington

文章写了啥

1. 发现现有的基于单一介质的文件系统并不能同时满足大容量，高性能，性价比高的需求，所以提出了多种介质混合的想法；
2. 通过发现用户态和内核态切换开销所占比例过大，设计了LibFS和KernelFS两者功能各司其职又相互协作的文件系统，其中LibFS拦截了系统调用，自己实现了用户态的库，通过mmap( )的方法直接写到NVM上，然后再在内核态中进一步的digest进去，这一做法十分新颖且高效。

KEYWORDS

• File system, Non-volatile memory, Multi-layer storage
• 文件系统，非易失性存储器，多层存储

ABSTRACT

当前的硬件和应用存储的发展趋势给操作系统的存储子系统带来了巨大压力。

1. 在硬件层面上，由于成本和性能的重要原因，导致存储设备市场已经变为跨越多层次的多层存储拓扑结构。
2. 在文件系统层面上，应用越来越需要能够针对大规模数据集实现低延迟、高吞吐量、简单化崩溃一致性的的小型、随机的IO。
3. 为单个存储层设计的文件系统并不能同时支持这些需求。

• Strata,它是一个可以利用一种存储介质的优点来弥补另一种的弱势的的跨存储介质文件系统。通过这样做，Strata可以同时提供性能、容量和简单同步IO模型，并且它的设计比受限于单层存储设备的文件系统更简单。Strata的核心在于使用了一种在用户模式、内核和存储层之间进行新型任务划分的日志结构方法，而这种划分会将可伸缩性、高性能持久化从存储层管理中剥离出来。
• 使用仿真NVM、基于闪存的SSD和高密度的HDD构建的三层存储结构来量化Strata的性能优势。与为每层单独构建文件系统的方案相比，Strata在延迟和吞吐量性能上有了20-30%的提升，并提供了对整个存储结构的同步和统一访问。最终，与Linux 逻辑卷管理器提供的基于块的双层Cache缓存相比，Strata实现了2.8倍的吞吐量提升。

1 INTRODUCTION

文件系统正承受着上游应用和下游设备的压力。

• 在文件系统的下层，基于性能和容量的权衡，存储设备市场已经开始分化，现在的很多系统都是使用固态硬盘和传统机械硬盘。NVM将以与二者不同的第三种的容量和性能表现来给予另一种存储设备选项。
• 在文件系统的上层，现代应用程序的性能和功能性需求远远超出了传统文件系统所能提供的。例如：
  1. 通常情况下的内核旁路技术
  2. 对大规模数据集的小规模更新
  3. 对程序员的易操作性
  4. 高效的崩溃一致性处理

为了解决这些问题，提出了一个集成的跨存储介质文件系统Strata。

• 为了更好地利用多层存储的硬件属性.
• 虽然设计思想可以在NVM和SSD的特定文件系统中找到，但我们仍然是第一个去设计、构建和评估跨NVM、SSD、HDD三层的文件系统。

2 BACKGROUND

1. 回顾当前和近期的存储设备，并讨论Strata如何应对这个多元化市场。
2. 讨论现代应用程序对文件系统的需求以及当前可选方案的不足之处。

2.1 Hardware storage trends 硬件存储趋势

• Diversification 多元化

  • 三种存储技术竞争：非易失性存储器（NVM），固态硬盘（SSD）和高密度硬盘驱动器（HDD），各自有优点。

  • 针对Table 1 进行性能展开

  • 多样性表明未来的系统可能需要几种共存的存储技术。

• Device management overhead 设备管理开销
  • 现代存储设备地物理特性会阻止有效更新。
  • 利用Strata的多层特性来达到SSD和HDD层的全部性能，NVM层会自动更新数据，

2.2 Application demands on the file system 应用对文件系统的需求

• 许多现代应用程序需要文件的崩溃一致性。在许多文件系统上，高效崩溃一致性对于应用来说是难以实现并且是缓慢的所以应用会选择牺牲正确性来换取性能优势。
• Strata提供语义(包括写入)给有序文件系统，这种方式对程序员友好并简化了崩溃恢复。

2.3 Current alternatives are insufficient 目前的可选方案不足

• Existing file systems specialize to a storage technology 采用特定存储技术的现存文件系统
  • 现存文件系统都针对特定类型的存储设备，没有单个文件系统能适用于不同的存储介质。
• File system write amplification 文件系统写入放大
  • 文件系统写入放大通常是限制应用程序性能的主要因素，尤其是对于支持高效小规模写入的NVM器件。使用将被摘要到块更新的NVM层的操作日志，Strata能够有效地聚合重复的数据和元数据更新，从而显著降低文件系统写入放大效应。
• Block stores are not the only answer 块存储并不是唯一的答案
  • Strata为应用程序提供了文件系统而不是块存储接口，因为文件系统具有很强的向后兼容性、性能和功能。

3 STRATA DESIGN

Strata的目标是设计一个新的文件系统，用来管理不同存储设备之间的数据，结合它们的优势并弥补它们的弱点。

Strata设计目标：

• Fast writes 快速写入
  • Strata必须支持快速，随机和小规模的写入。快速小规模写入的一个重要原因是支持网络服务器应用程序，这些应用程序必须在响应回复之前保留数据。
• Efficient synchronous behavior 高效同步
  • 在同步过程中尽量减少性能损失
• Manage write amplification 管理写入放大
  • 减少对性能和QoS(Quality of Service,服务质量)的不利影响
  • 方法：decoupled from the write fast-path 与写入快速路径分离
• High concurrency 高并发
  • Strata支持多个线程并发logging
• Unified interface 统一接口
  • 我们为整个底层存储结构中的所有设备提供统一的文件系统接口。 Strata的基本架构类似于日志结构合并（LSM）树。Strata首先将log同步写到NVM（write-efficient），然后周期性（异步）的digest到Kernel FS（per-file extent tree，read-optimized）。
• Log at user-level, digest in the kernel 用户级日志，内核级摘要
  • 为了实现快速写入，Strata分离日志和摘要的职责，并将它们分别分配给用户级软件和内核。
  • 内核级文件系统（KernelFS）负责摘要。
    • 摘要为了实现高吞吐量采用跨多线程并行完成的，后台异步运行。
• Sequential, aligned writes 顺序对齐写入
  • 通过启用顺序对齐写入，摘录可最大限度地降低设备写入放大。
• Use hardware-assisted protection 硬件辅助保护
  • 为了安全有效地绕过内核，Strata利用现代服务器系统中提供的硬件虚拟化功能。

3.1 Meta-data Structures 元数据结构

Strata将元数据保存在超级块、inode和空闲块的每层位图中。这些数据结构类似于其他文件系统中的结构，我们在此仅简要描述它们。

• Superblock
  • Strata的超级块存储在NVM中，其描述了每个存储层的布局以及所有应用程序日志的位置。每当创建或删除一个应用程序日志时，KernelFS会更新它。
• Inodes and directories
  • Inodes
    • Inode存储文件的元数据，如访问权限、所有者、创建时间、每个文件的extent tree的根。
  • directories
    • Strata的目录结构类似于EXT4，在数据块中保存了一个链式数组文件名和相关的inode编号。
• Free block bitmap 释放块位图
  • Strata中每层都有持久化位图来指示哪些块应该被分配和释放。
• Multiple device instances 多设备实例
  • Strata原型仅支持单层单存储设备，但设计将实现设备在逻辑上进行连接的单层多设备。例如，Strata可以将两个8TB的SSD作为一个16TB的SSD。该方法将允许Strata增加容量，冗余空间可以留作将来用。

3.2 Library File System (LibFS) 库文件系统

Strata的库文件系统（LibFS）提供了应用程序级别机制来执行文件IO。 其目标是为整个底层存储层次结构提供快速、崩溃一致和同步的读写IO，与现有POSIX应用程序完全兼容的统一API，并通过与LibFS重新链接将其置于应用程序之下。

• Fast and synchronous persistence 快速和同步持久化
  • 现代NVM存储技术使Strata能够在不牺牲性能的情况下提供同步IO语义，同步语义可以加速NVM的整体IO性能。
  • 同步语义允许Strata提供零拷贝IO——LibFS直接在用户的DRAM缓冲区和NVM之间执行IO。
  • LibFS将更新日志以操作日志方式组织。操作日志比数据日志相比减少了IO，因为操作日志只需要指示目录更改的记录，而数据日志需要多个块记录。
• Crash consistent logging 崩溃一致的日志记录
  • LibFS将更改记录到包括文件和目录元数据在内的所有文件系统状态中。所有数据都按系统更改的顺序附加到日志中，而日志可以有效提供崩溃一致性更新。
  • LibFS具有被称为Strata事务的持久化单位。
• Digest and garbage collection 摘要和垃圾回收
  • 日志是有限的资源，需要定期摘录到共享区域并进行垃圾回收。 一旦日志填充超过阈值（我们的原型中为30％），LibFS就会向KernelFS发出摘要请求。KernelFS在后台异步摘要日志，并在摘要请求完成后回复LibFS。 完成后，LibFS可以通过重置每个日志头的有效位安全地回收日志条目（也是在后台）。 Strata的数据结构允许用户将记录添加到内核正在摘录的日志中。
• Fast reads 快速读取
  • LibFS在DRAM中缓存数据和元数据。 只有从SSD或HDD读取时才会缓存数据，NVM中不需要缓存。
  • 要解析具有最新数据的文件位置，LibFS会搜索文件数据缓存、更新日志和从最高NVM存储层到最低HDD层的extent tree。

3.3 Kernel File System (KernelFS) 内核级文件系统

Strata的内核级文件系统（KernelFS）负责管理系统中全局可见和的可驻留在存储结构的任何层中的共享数据。 为此，它会摘要应用程序日志并将其转换为perfile extent树。 摘要在后台异步发生，允许KernelFS批处理Strata事务并定期进行垃圾回收和优化物理布局。 LibFS向KernelFS提供最近最少使用（LRU）的信息，以在存储结构的各层之间通知其迁移策略。

• Digest 摘录
  • 为了减少摘要延迟，KernelFS采用许多优化操作：
    1. 从日志中摘要大批操作
    2. 合并相邻写入
    3. 识别和消除操作
• Data access pattern interface 数据访问模式接口
  • 为了了利用整个存储结构，KernelIFS会在不同层间迁移数据，Strata在Kernel FS中维持了两个LRU list，一个用于NVM-SSD之间的数据迁移，一个用于SSD-HDD之间数据迁移。
• Data migration 数据迁移
  • 为了利用存储层中的容量，内核会在后台进行不同层间地迁移数据。为了并发操作并避免迁移阻塞带来地延迟，Strata会在层满前就进行数据迁移(在该原型中利用率为95%)。为了减少开销，写入到SSD是以erase为单元（百兆级别），写入到HDD是以木瓦磁盘方式（GB级别）。

3.4 Sharing (leases) 共享(租约方式)

Strata支持POSIX文件共享语义，同时优化对不同时共享的文件和目录的应用程序访问路径，KernelFS支持对文件和部分命名空间文件的的leases租约方式共享。

• 文件数据的粗粒度顺序共享，租约具有低执行时间开销。
• 由于其高开销，细粒度数据共享进程使用共享内存或管道

租约允许LibFS对特定文件或以某个目录为根的文件系统命名空间区域的独占写入或共享读取访问。写租约的功能类似于独占锁。

3.5 Protection and performance isolation 保护和性能隔离

• Protection with kernel bypass. 内核旁路保护
  • Strata支持对POSIX文件的访问控制，由MMU和NVMe命名空间强制执行，
    • MMU为内核旁路LibFS提供保护
    • 对于SSD驻留数据，使用NVMe命名空间来保护对文件数据的访问
• Performance isolation 性能隔离
  • 写入放大通过提高设备带宽利用率来提高IO的性能隔离。

3.6 Example

举例：覆盖一个非共享文件中的首1KB数据，之后读取前4KB数据。

4 IMPLEMENTATION

• 实施方案
  • 使用英特尔的存储性能SDK绕过Linux内核而快速访问NVMe SSD
  • 使用英特尔的libpmem来对模拟NVM持久化数据
  • 使用非时序写入来避免污染处理器cache
  • 使用适当的store fence和cache的刷新来保证持久化
  • 使用EXT4文件系统的extent tree，并对其进行修改实现日志结构更新
• 结果
  • 完成了LevelDB键值对存储测试套件的201个单元测试以及Filebench中所有测试

4.1 Limitations

• Kernel
  • 由于上下文的切换，导致系统调用的开销较高
  • 但我们认为影响很小，因为设计目标是最小化内核级系统调用
• Leases
  • 租约并没有完全实施
• Memory mapped files 内存映射文件
  • 由于目标应用不会使用内存映射文件，所以这里没有做实现
• Fault tolerance 容错机制
  • 目前没有做任何冗余来补偿存储设备故障问题。

EVALUATION

• Tested 测试环境
  • 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

5.1 Microbenchmarks 微基准测试

• Hardware IO performance
• File system write efficiency
• Latency
• Persistent RPC
• Log size sensitivity
• Throughput scalability
• Data migration
• Isolation

5.2 Filebench: Mail and Fileserver

• 原因: 因为邮件服务器会访问并创建/删除很多小文件，所以可以很好衡量Strata的元数据管理。文件服务器与之类似，但操作文件时较大，而且有更高比例的文件IO操作。
• 使用Varmail负载以及Fileserver负载
• 配置：10000files/32KB(avg for varmail) & 128KB(avg for fileserver)/16KB appends/ 读写比1:1(for varmail) & 2:1(for fileserver)/两种工作负载都以1MB的粒度读取和写入数据
• 测试结果：table 6
  • 与VarVA相比，Varmail在Strata上的写入吞吐量提高了26％
  • Fileserver吞吐量的改进较小（与NOVA相比为7％）。这是预期结果：Fileserver具有更大的平均写入大小并且没有崩溃一致性协议。
• 结论：Strata的日志压缩策略非常适合Varmail

5.3 Data Migration

• 为了测试Strata使用多个存储设备时的性能，我们将Fileserver配置为1MB，1000files。在这种情况下，工作集一开始在NVM中运行，但随后会digest到SSD和HDD。
• 结果：Figure 7
  • Strata和UDM在LVM之上的吞吐量都比F2FS高2.8倍。
• 结论：Strata可以在高速层获得更多元数据来加速文件系统数据结构的遍历

5.4 Key-value Store: LevelDB

• 这里运行很多LevelDB基准测试，测量平均操作延迟。
• 结果：table5。
  • 无论工作负载如何，LevelDB在Strata上实现的延迟低于任何其他NVM文件系统。
• 结论：如果底层存储设备速度很快，具有简单同步IO接口的文件系统可以提供低延迟IO。现代应用希望逻辑一致的更新可以得到崩溃恢复，而Strata通过简单的恢复语义可以实现这样的系统。

5.5 Redis

• Redis是一个通常用于复制的分布式场景的键值对存储。
• Standalone.
  • 单个Redis实例进行基准测试，吞吐量提高了22%
• Replication
  • Redis支持复制以实现容错
  • Strata相对于EXT4-DAX，吞吐量提高了29％，并且比NOVA保持了5％的改进。

6 RELATED WORK

1. Logging and coherence in file systems日志记录与文件系统的一致性。
2. Multi-layer block stores 多层块存储
3. NVM/SSD optimized block storage/file systems NVM/SSD优化块存储、文件系统。
4. Managed storage design 可管理存储设计。
5. Strong consistency 强一致性。

7 CONCLUSION

存储硬件的趋势促使多层存储拓扑在成本和性能方面有巨大优势。 文件系统应管理多存储层，以提供高效的小规模写，同步语义和强QoS保证等高级功能。