Introduction
多流机制
多流提出的背景：底层介质随着老化而碎片化，垃圾回收的影响会使SSD运行效率急剧下降，并且缩短SSD的寿命。（写放大问题及SSD磨损问题）
因此需要一种方法减少碎片化，有研究提出多流（Multi-Streaming）来解决这个问题。
多流机制：提供一种方法（由流抽象）供上层来指示数据如何放置在SSD底层物理介质上。标记为同一流的数据会尽量放置在同一物理地址上。
粗浅解释：主机对于下发到SSD的数据，会在某一层对其标记所属的流，并且标记会通过协议层（NVMe、SCSI等）传递到SSD，SSD通过内部FTL将不同流的数据放置在不同物理地址区域，从而实现了不同生命周期的数据的分离，减少了碎片化。
多流设计的核心：主机在数据传输的哪一层对数据进行流标记？根据什么来判断数据属于哪一个流？
第一个问题是本篇论文区别于先前研究的关键，同时本文也给出了第二个问题的方案。
本文设计与之前设计的区别
FStream主要设计是在文件系统层对数据进行分流，区别于先前研究的设计。
先前研究对流利用的策略主要分为两类：
- ①应用级定制，基于对数据的预期生命周期的理解，将应用程序数据映射到不同的流（例如，将LSM的不同层映射到不同的流），对NoSQL数据库非常有效。
- ②块级自动化定制，根据过去的LBA访问模式预估生命周期给数据分配流ID，在工作负载变化的情况下不能很好地工作。
上述策略体现了决定在哪一层次对数据进行流分离的两个极端，一个由应用程序分配流，另一个由设备驱动层分配流。而本文设计的分配层次位于中间（文件系统）。
Design
由文件系统分配流的动机
相比应用程序与设备驱动层，文件系统分配流的优势如下：
- 相比应用程序，文件系统了解自己元数据的生命周期和更新频率。（文件系统元数据的更新频率与应用数据的更新频率不同）
- 设备驱动根据LBA访问模式预估生命周期来分配流，不能很好地适应不同工作负载。
虽然文件系统会在逻辑上保持数据与元数据分离（它们生命周期与更新频率差异很大），但是在SSD上并不能保持它们“物理”上分离。而FStream会通过流保证数据与元数据在SSD上的分离，降低WAF并提高性能。
简单来说，文件系统是能分离文件系统元数据与数据的最高层次，因此在这里对元数据与数据进行流分离。
具体设计
FStream选取了Ext4与Xfs进行流感知的修改，以证明其设计的有效性。
Why Ext4 and Xfs：这两个文件系统都是日志文件系统，对元数据写入会使用日志来保证一致性，因此对SSD除了有数据的更新写入，还会有大量元数据的更新写入。因此修改这些文件系统能更有效地表现出用多流分离元数据所带来的性能提升。
对Ext4以及Xfs的多流分配如下图。
简单来说，做法就是在一些数据结构里加入streamid字段，在文件系统缓冲区被刷新时给字段赋值，传递到bio及更下层，最后交给SSD FTL依据streamid进行数据的分离。
Experiment
这里引用原文摘要的实验结果，不详细说明。
实验结果表明，FStream将filebench性能提高了5%~35%，并将写放大因子降低了7%~46%。对于NoSQL数据库基准测试，性能提高了38%，WAF降低了81%。
Thought
概括
总而言之，本篇论文在提出了一种在文件系统层次上应用多流技术的方法。以前的研究要么在应用程序级利用多流，需要修改应用程序并且只能对应用数据分流；要么在设备驱动层利用多流，优化效果较差而且不能适应负载的变化。
论文主要关注文件系统生成的数据的属性，比如是数据、元数据还是日志等，根据这些来进行多流的设计。最终实验证明了该设计的有效性。
思考
往回看
为什么需要提出多流？这是因为发现了SSD随着使用的老化，其内部碎片化变得严重，使GC效率下降而且对SSD寿命有不利的影响。
为了减少碎片化，同一时期学术界提出了Open-Channel SSD（OCSSD）以及Multi-Streamed SSD（MSSSD？不确定简写），这两种方案一个是将SSD FTL交给主机来管理，一个是提出了流的概念，使得主机能够在一定程度上控制数据在盘上的物理分布。
两个方案的共同点是让主机更多地参与了数据在SSD物理地址上的放置分布，而不是完全由SSD来决定数据放置在哪里。在OCSSD中，主机直接将传统SSD内FTL的活抢过来干；而MSSSD中，则是主机与SSD进行了更多的交流。
更深层的，碎片化的成因是数据从主机传递到SSD途中存在信息的缺失。
- 如果应用了解SSD内部的一切：数据的放置方法可以完全由应用程序设置，那么通过增加应用程序代码的方式，完全可以做到碎片的最小化。但是为了减少主机计算的压力，以及满足隔离、虚拟化等需求，不可能如此设计。
- 又或者是SSD完全了解应用：SSD知道传来的数据属于哪一个应用、是冷是热、生命周期多长，那么根据这些信息，SSD可以将不同属性的数据分离放置，同样可以做到碎片的最小化。但是这会极大增加数据传输的压力，而且文件系统、协议、SSD的设计会十分复杂。
为了弥补这种信息的缺失，从以上两种方式分别进行了做出权衡的设计：
- OCSSD，让主机来管理原属于SSD的FTL，变相的使主机了解SSD内部知识，对应也增加了主机计算的压力。
- MSSSD，使SSD通过流得知了应用的很小一部分信息，从而可以有意识地对不同属性的数据进行分开放置。
有没有其他方式？其中有两个关键：
- 弥补信息的量：传递哪些信息，数据属于哪个应用、数据的冷热、数据的生命周期等等。要有选择地传递这些信息，否则会令数据传输变成瓶颈。
- 如何进行信息到数据具体放置方法的转换：在了解到这些信息后，如何根据信息实施对数据的放置方案？以及在哪一步进行这个转换（OCSSD在主机进行，其他SSD在FTL层进行）。
由于信息只能从最上层向下传递，因此SSD所了解到的信息，其上的每一层都会了解（应用、文件系统、驱动层等等）。因此要谨慎设计SSD所能获得的信息量。
往后看
OCSSD已经往后走了一步，到达了ZNS SSD的阶段。这一步的原因是如今IO栈的瓶颈存在于软件，设备的性能要高于软件的性能，也就是说对SSD进行优化获得的增益不高，应该缩短软件的IO栈或者将软件的负担卸到设备上。OCSSD的设计违背了这个想法，过度增加了主机的负担，因此ZNS将FTL的部分功能交还给SSD来做。
那么MSSSD是否能向后走一步？目前还没有看到基于Multi-Streaming的新设计出现。暂时只能想到扩展流的内容。
除了这两条路径，还有一个可能：把主机做的事交给SSD来做。
回到多流
回到论文本身讨论的多流，现在已经有三种方法实现多流，分别位于应用程序、文件系统以及块设备驱动层。难以想到如何以其他方式实现多流。最新的文章更多研究的是流分配的算法。