0x00 Everyday English

Heterogeneous 各种各样的

semantic 语义上的

conservative 保守的、传统的 —aggressive 激进的

aggregate 合计

orchestrate 精心策划

proactive 积极主动的

by means of 通过，借助于

off-the-shelf 现成的

elaborate 详细阐述

0x01 Intro

随着存储技术的发展，由SCM、SSD、HDD以及一系列云存储构成了目前异构存储系统

异构存储系统将冷数据放在更慢的层次，热数据放在更快的层次，存储机制的激进和保守都会带来一些性能损失，而且异构存储系统由不同速度和特点的存储设备组成

在异构存储系统中，还存在前台和后台I/O的干扰问题，带来明显的延迟，硬盘的管理层往往不能分辨出I/O请求的优先级高低，并决定将其数据存储到哪一层次

这种情况被称为I/O栈高层次与底层存储系统之间的语义鸿沟，其中一个解决方案为使用I/O access hints，当app读取一个文件时，文件块可能散落在不同设备中，上层可以告知存储系统，使得存储系统提前将该文件的数据汇总到读取速度更高的层次，本文提出了一个分类器，允许存储后端控制器针对不同的I/O指令实施不同的I/O策略，例如SSD可以优先处理元数据和小文件，使其先缓存至文件系统中

本文提出了一个通用灵活的框架，HintStor，为异构存储系统提供access hints

设计和实现了一套新的用户层面的接口，文件系统插件，块存储数据管理器，在存储管理方面，HintStror通过在block级别进行统计（热力图等）来触发数据迁移，并通过FIFO队列处理I/O；HintStor还提供了access hint的评估，有以下几个要点：

• 新的app/user层面的接口允许用户定义和配置新的hint
• VFS中的文件系统插件提取文件布局信息并建立文件层面的数据分类器，用于下层各种文件系统
• 在基于DM的Linux中，块存储数据管理器实现了四个原子access hint操作，触发数据迁移和I/O调度，因此可以执行和分析与上层hint有关的不同策略

作者基于SSD、HDD、SCM以及云存储进行了评估，以体现系统的灵活性，实现并分析了以下四个hints：

• 使用文件系统内部的数据进行分类（元数据，文件数据，文件大小）
• Stream ID，该ID用于对不同数据进行分类，并将相关数据存储在一起或紧密地存储在同一个设备上
• 云预取，cloud prefetch，调研了在access hints情况下，如何帮助有效地集成本地存储和云存储。
• I/O任务调度，用户可以在应用层面向块存储设备发起hints，来对前台和后台任务进行区分

0x02 Bg

在目前的hints机制中，主要考虑的是宿主机的page cache和预取机制，目前system中的系统调用可以通过指定一个随机访问flag来告知内核选取正确的预取和page cache策略以优化对某个文件的访问。

目前很少有对异构存储系统的优化，需要解决的问题是在不同的存储设备上的智能数据移动，fadvise()和inoice()系统调用可以改善prefetching，但是不能解决数据移动问题。

MPI-I/O hints在高性能计算系统中优化文件系统，目前这些研究着眼于优化存储系统中的buffer/cache部分，red hat通过在用户空间限制I/O来对不同供应商的存储设备进行block对齐。

目前有些文件系统支持自定义类别，btrfs可以在同一文件系统中支持不同的卷，同时需要用户为存储设备静态配置卷，用户可能让多个应用运行在一个逻辑卷中，为了实现高效的数据管理，作者考虑在卷上支持动态的access hints。

0x03 HintStor Design

Overview

HintStor的架构图如上图所示

Device Mapper是一个开源框架，为由多种块设备组成的卷提供映射

整体包含三层，在应用层、文件系统层、块层提供了新的接口和插件

• 在用户层通过接口连接Block Storage Data Manager和文件系统，使得应用可以接受数据和发送access hints
• 为了提取chunk的文件系统语义，HintStor将一个插件绑定到文件系统层，来利用内部文件的文件数据结构和文件数据布局
• 为了控制对大chunk的数据管理，HintStor实现了新的block storage manager，可以实现对存储设备的access hints策略

在Device Mapper中实现了两个功能：

• Redirector 将I/O请求转发到相应的设备
• Migrator 提供块设备间的异步数据拷贝，为了防止拷贝过程中对带宽的占用，会对流量进行限制，迁移后会通过一个flag来决定是否删除拷贝的原始数据

Interface

HintStor使用sysfs接口为I/O请求设置一些属性，与块设备和文件系统通信，类似于一个伪文件系统，可以从其他内核的子系统中提取信息。

在内核实现了部分系统调用，使用JSON格式的请求进行通信，JSON的编解码可能有性能损失？

一些应用程序可能要对代码进行少量修改

File System Plugin

HintStor可以获取与请求相关的data block信息，提前触发数据迁移，优化后续的访问

HintStor可以区分前台和后台I/O ，优先对前台I/O进行满足

HintStor在VFS提供了一个FS_HINT调用，用于获取文件的数据布局信息，获取文件系统元数据，该接口供用户空间和应用进行调用，同时支持查询多个文件的映射。

该功能提供在ext2、ext4和btrfs等Linux中主流的文件系统中

FS_HINT会维护ext4预分配的block group，btrfs可以将一个块设备挂载为sub-Volume，用于跨设备管理数据

通过ioctl接口来获取文件的边界，来触发数据迁移或者I/O调度

Block Storage Data Manager

主要包含：

chunk的映射表：

• 维护LBA到Physical Block Address的映射
• chunk size 可自定义

chunk-level I/O 分析器：

• 用于监控每个chunk上的I/O访问统计信息
• 估算每个chunk的访问频率，生成热力图，该信息用于周期性的进行数据迁移
• 虽然这些信息可能不准确，仍然可以用来作为数据移动的正确性评估指标
• 当chunk被迁移到更低速的层次，访问频率可能会升高，进而将数据转移到更快的层次

chunk 调度器：

• 用于评估不同任务的优先级进行调度
• 目前支持一个工作队列和一个等待队列，默认使用FIFO机制来维护原有的请求顺序
• 当任务优先级相关的Hint发起时，会将低优先级的请求放到等待队列尾部
• 应用可以设置一个定时器来调用一个请求，用于将接近deadline的请求从等待队列移动到工作队列

access hinit原子操作的分类模型：

• HintStor将数据的布局和移动视作改善异构存储系统的基本功能
• 每一个access hint指令是一个四元组(op,chunk_id,src_addr,dest_addr)，包括操作类型、chunk ID、在逻辑卷中的源地址和目的地址
• 共有四个原子操作：
  • Redirect：当最初请求的原地址被重定向到其他地址时触发，例如在一个由多个SSD和HDD组成的逻辑卷中，可以将存储到HDD上的较小的文件重定向到SSD中。该处理函数会调用DM中的驱动并管理被重定向的请求，当bio到达DM时，将对data chunk重新赋值为目的地址
  • Migrate：作为HintStor中关键的部分，在后台会保留一个migration daemon后台驻留程序，起初当数据块存放于不同的存储设备时，数据的访问频率会时不时发生变化，Migration操作通过调用DM中的migrator target driver，将data chunk从原有的位置转移到目的位置。为了保证一致性，迁移过程中该chunk将加锁进行保护，忽略对chunk的访问。HintStor提供主动和策略两种迁移方式，主动即用户主动触发，同时实现了基于时间的启发式迁移策略，可以配置为每两个小时迁移top-k访问最频繁的chunk到更快的存储设备中
  • Replicate：用于将数据的副本进行保留，使用DM中的migrator target driver，保留原来数据的指针，使得热点数据分布在多个存储设备上，提高数据访问的平均时间，同时可以利用Replicate创建数据的多个副本，需要加锁
  • Prefetch：类似于Buffering， HintStor预留一个buffer space空间用于预取，将data chunk加载到buffer space中，实现类似于Migrate和Replicate，主要区别是Prefetch在拷贝时不需要加锁进行保护

Classification

I/O access hints可以分为两种，分别为从操作系统动态地进行捕获和从文件系统静态地获取

动态的access hints主要帮助块存储设备在运行时管理数据的布局，对于冷数据，便于文件系统进行预取。

HintStor在chunk级别处理I/O请求，并且绑定一些额外的信息，例如文件结构和用户的提示，任务调度则在进程level实现

Conclusion && Thinking

• 对比Flash Share，HintStor主要针对Linux I/O栈和文件系统层面，Flash Share 还考虑到了NVMe协议方面和SSD层面
• 在处理前台/后台I/O部分二者比较类似