XFS：大数据环境下Linux文件系统的未来？
XFS：大数据环境下Linux文件系统的未来？
Linux有好多种件系统，但往往最受关注的是其中两种：ext4和btrfs。XFS开发者Dave Chinner近日声称，他认为更多的用户应当考虑XFS。他谈到了为了解决XFS中最严重的可扩展性问题所做的工作，还谈到了他认为将来的发展走向。如果他说的一点都没错，接下来几年我们在XFS方面有望看到更多的动静。XFS经常被认为是适合拥有海量数据的用户的文件系统。Dave表示，XFS非常适合扮演这个角色；它对许多工作负载而言向来表现不俗。以前往往问题出在元数据写入方面；对生成大量元数据写入操作的工作负载缺少有力的支持历来是该文件系统的薄弱环节。简而言之，元数据写入速度很慢，扩展性欠佳，甚至只能适用于单个处理器。
速度到底有多慢？Dave制作了几张幻灯片，显示XFS与ext4相比的fs-mark结果。哪怕在单个处理器上，XFS的表现也要差得多（速度只有ext4的一半）；如果线程数量多达8个，情况完全变得更糟；但线程数量超过8个后，ext4也遇到了瓶颈，速度慢下来。就元数据频繁变化的输入/输出密集型工作负载（解开tarball文件就是个例子）而言，Dave表示ext4的速度可能比XFS快20倍至50倍。速度这么慢足以表明XFS确实存在严重问题。
延迟的日志
结果表明问题其实出在日志的输入/输出上。针对元数据的变化，XFS会生成大量的日志流量。在最糟糕的情况下，几乎所有的实际输入/输出流量都用于日志——而不是用于用户试图想要写入的数据。多年来人们试图采用多种办法来解决这个问题，比如对算法进行重大改变，另外进行许多重大的优化和调整。不需要的一点是任何一种磁盘上格式变化，不过这在将来可能由于其他原因而在筹划之中。
元数据密集型的工作负载最后可能会在很短的时间内多次改变同一个目录块；那些改变每一次都会生成一个记录，记录必须写入到日志中。这正是导致巨大日志流量的根源。解决这个问题的办法从概念上来说很简单：延迟日志更新，并且将针对同一目录块的变更合并到一个条目中。这些年来，以一种可扩展的方式实际落实这个概念颇费周折，但是现在取得了进展；延迟的日志（delayed logging）将是3.3内核中唯一得到支持的XFS日志模式。
实际的延迟日志技术主要由ext3文件系统借鉴而来。由于这种算法已知切实可行，证明它同样适用于XFS所需的时间则短得多。除了性能上的优点外，这一变化最终促使代码数量减少。有谁想详细了解其工作原理，应该会在内核文档树中的filesystems/xfs-delayed-logging.txt找到所需内容。
延迟日志是一大变化，但绝不是唯一的变化。日志空间预留快速路径是XFS中非常热门的路径；现在它是无锁的，不过慢速路径现阶段仍需要全局锁。异步元数据写回代码形成了非常分散的输入/输出，结果大幅降低了性能。现在，元数据写回在写出之前已被延迟和分类。用Dave的话来说，这意味着文件系统在做输入/输出调度程序的工作。但是输入/输出调度程序处理的请求序列通常限制在128个条目，而XFS的延迟元数据写回序列可以有数千个条目，所以有必要在输入/输出提交之前在文件系统中完成分类操作。“活动日志项”（Active log item）这种机制可以累计变化，并批量运用变化，以此改进（庞大的）分类日志项列表的性能。元数据缓存也被移到了页面缓存器的外面，页面缓存器往往会在不合适的时间收回页面。等等。
|
评论暂时关闭