用于闪存的多核加速文件系统调研实验及分析

描述

1. 背景

随着固态硬盘带宽的快速增长,其访问延迟在不断缩小,在CPU核数的不断增长下,我们希望文件系统可以配合这种核数的扩展尽量释放SSD的全速带宽,但是在过去的实践中,传统文件系统只对于传统的HDD等设备具有更好的多核扩展性支持,通过在NVMe SSD上的实验发现,当核数扩展时文件系统的性能表现较差。

2. 调研实验及分析

1) 实验设置

在每个核上运行一个进程,并按照从1到72的规模扩展CPU核数,每个进程运行60秒,并执行创建文件、写操作、同步操作、删除文件等操作内容。在此过程中测试XFS、ext4、SpanFS、F2FS和模拟理想文件系统对于不同类型设备的吞吐量数据。

2) 实验结果

处理器

实验结果显示,现存文件系统对于NVMe SSD的多核扩展性支持相对较差,而对于传统的HDD和SATA SSD的扩展性具有接近于理想条件下的支持。同时最右边的图表显示,在72核的规模之下,大部分文件系统无法高效利用NVMe SSD的高速带宽。

3) 原因分析

i. 并发控制层的锁缓存争用

对于文件系统中支持并发访问的共享锁,由于锁的计数值需要在各核之间共享,那么就会引入计数器的缓存一致性问题,因此当核数增加时这种维护开销就会更加明显;

ii. 内存数据结构层的顺序化

LFS将内存数据结构分为三个区域:inode表、inode区域和data区域,对于每个区域,F2FS都会用一个radix树的结构进行管理,并且在每一棵树上用读写锁来进行并发控制。随着并发写者数量的增加,访问这三种树时会造成严重的顺序化,进而造成性能的下滑。

iii. 空间分配层的数据化

虽然F2FS采用了多头日志的形式并行化IO请求,但是由于各个温度的数据间的内部依赖,实际的数据持久化请求会被序列化(例如为了保证F2FS的冲突一致性,数据块持久化必须先于inode的持久化,同时文件inode的持久化必须在目录数据块更新之前)。因此,这种多头日志的设计对于扩展IO吞吐量没有很明显的优势。

3. 设计

为了充分利用多核架构和现代NVMe SSD的高带宽特性,我们设计了Max-针对闪存的多核加速文件系统,与F2FS的架构对比图如下:

处理器

根据实验分析的三个层面的问题,分别给出解决方案:

1) 设置每内核读者信号量,读访问可以并发进行,每个内核维护一个读者计数,各个内核的计数值互不相关,避免了在内核间维护缓存一致性的开销。当有一个写请求出现时,各个内核不再处理新的读请求,把当前正在进行的读请求处理完成后再处理写者的写访问。利用CPU调度器来高效检查每内核计数值,不必引入额外开销。

2) 将内存数据结构的索引划分为多个文件单元,每个文件单元包含单个文件的 inode 表项、inode 页和数据页,利用多棵树的索引实现并行化。

3) 将每种类型的日志区域切分为更小粒度的日志,每个小日志负责自己空间的分配,各小日志之间的空间分配互不干扰。

4. 实验效果

处理器

实验结果显示,MAX在数据访问和元数据访问带宽都实现了较好的多核可扩展性,与原始的F2FS等文件系统相比具有良好的优化效果。



 


审核编辑:刘清

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分