OrcFS: Orchestrated file system for flash storage
这是一个 acm的A类文章
ref：https://dl.acm.org/doi/10.1145/3162614
1.Introduction
SSD的市场份额越来越大，价格也越来越便宜，但是DRAM的开销特别大。同时，应用层，文件系统和FTL层面都在做相关努力来利用SSD的物理特性，但是他们各个层面之间是有冗余的。
之前也有在文件系统和FTL层面协同处理的，但是他们没有考虑GC的性能和page size不一致的写放大，让之前的处理难以应用到实际场景。
之前也有很多冗余去除的方法，区分与之前方法的差异主要有以下三点：(1)文件系统直接管理mapping table. (2)避免段清理影响QoS. (3)block patching的方式避免写放大。
- Background
2.1 Segment Clean in Log-structured File System
log-structrued file system将数据和元数据的写集中起来，顺序刷下去。原来无效的数据需要做空间清理才能被再次分配。但是，空间清理影响QoS，会带来无法预知的延迟。
2.2 Garbage Collection in Flash Storage
SSD上的垃圾回收已有的算法：Greedy,EF-Greedy,cost benifit.还有一些提出是为了QoS的，比如back ground, preepmtive.
TRIM,Multi-stream ID能够最小化GC，但依旧是一个大问题。
2.3 Redundancies across the Layers
将随机写变成顺序写有一些优势，主要是垃圾回收和page mapping的效率。跨层之间的冗余总结下来有以下几点：(1)mapping information.(2)segment clean.(3)over-provisioning area.
已有的解决方法虽然能够减少冗余，但是尾延迟没有解决。同时，也没有解决单页的写在block mapping的写放大问题。
3.Design:Orchestrated File System
3.1 Concept
OrcFS将FTL的部分功能，address mapping, Garbage Collection给文件系统。
主要的思想是数据和元数据分开管理。数据不需要mapping table而元数据则是page mapping。这样的话，磨损均衡要怎么做呢？如果要分开管理，他们之间的更新频率？如何overprovisioning?
3.2 Disaggregate Mapping
segment为单位能够利用SSD的内部并行性，冷热程度划分和F2FS一样。这种方式SSD不会有over provisioning,因为没有必要。这种mapping的方式和hybrid mapping是不一样的。
3.3 Quasi-Preemptive Segment Cleaning
section的大小很大，如果valid的数量多，那么就会影响相关 的 foreground I/O。GC的触发为空间小于5%，分为foreground 和back ground GC，GC的时候具有互斥性，不能做正常的读写。write()系统调用会被阻塞，read()系统调用不会。
SSD有很多先发制人的GC算法，但文件系统要用到的话就需要保存内核状态。所以这里提出了QPSC。非阻塞的写和非阻塞的垃圾回收都是为了减少主机写的延迟，但是前者的目的是为了减少page cache miss的危害。
该算法主要是设置了一个定时器，在定时器时间终结后，去看是否有write()指令挂起。若有，则释放锁，然后去执行相应的写。具体的检查方式：在VFS有重要的写请求inode列表，在bdi_writeback的数据结构中的 b_io中。写完之后，再继续未完成的GC。
在实现上，用了SC_context暂存了最近清理的segment。
3.4 Bad Block Management and Wear-Leveling
坏块管理是SSD 在做，磨损均衡文件系统可以利用S.M.A.R.T信息，而FTL则可以根据文件系统给的冷热程度信息做super block级别的磨损均衡。
3.5 Block Patching
文件系统逻辑页和SSD物理页大小不一致导致的写放大的解决方法：request merge,sub-page mapping,read-modify-write. 虽然merge操作能够一定程度上减少开销，但是还是有不足之处。
但是说实话，只有元数据有这个困扰。就是说，block mapping的时候，如果有一个4k的page需要更新，那么整个block都需要更新。这种方式真的有效果吗？
