Bcachefs 1.38.6 - 性能发布版

# 1.38.6 - 性能发布 | Kent Overstreet 来源：https://www.patreon.com/bcachefs/posts/1-38-6-release-161366372 创作者头像 ## 1.38.6 - 性能发布 https://evilpiepirate.org/git/bcachefs-tools.git/tree/Changelog.mdwn 我想已经有一段时间没有写正式的公告了。唉，文件系统工程师/维护者/什么都做/无论现在你如何称呼我所做的事情，生活总是忙碌。 那么，来简单回顾一下： - 我们不再是实验性了。几个月前我就把网站上的实验标签去掉了——基于我惯常的判断："新收到的bug报告在减少，严重程度也大大降低，处理起来也比以前容易"。把这当作迟来的官方公告吧 :) - 对于那些新来的或错过了之前公告的人，回顾过去六个月的大新闻： reconcile（协调）和纠删码（erasure coding）。Reconcile极大地简化了设备和数据管理，它通过一个状态机引擎追踪所有数据的实际状态与期望状态之间的差异；它能响应选项和设备状态的变化，在后台移动数据，重新复制，应用选项变更（例如开启纠删码）。它被设计得很快；旋转设备上待处理的reconcile工作按物理LBA顺序索引，这意味着我们可以执行诸如"撤离"（evacuate）这样的技巧：在文件系统中的其他设备上找到被撤离设备上的所有数据副本，从而在所有设备之间并行执行撤离，且顺序十分规整。 - 纠删码：高性能且无写漏洞（write hole）。纠删码的实验标签已移除，它已投入使用且运行良好。Bcachefs的纠删码采用Reed/Solomon算法，与传统的RAID5/6完全相同，但没有写漏洞（不对现有条带进行原地更新）——并且不像ZFS，我们在不碎片化写入请求的情况下完成这一操作。条带是异步构建的，新写入的数据先被复制，当条带完成后这些额外副本就会被丢弃。分配器进行了优化，使得只要没有日志提交（即没有执行fsync操作），这些额外副本所在的bucket就能立即被重用（覆盖）。这意味着对于大块流式写入，额外副本只消耗总线带宽——它们在设备写缓存中时就会被覆盖。而且它与reconcile完全集成——开启纠删码选项后，它会在后台转换你的数据；如果设备发生故障，它会处理。 两者的文档都在用户手册中：https://bcachefs.org/bcachefs-principles-of-operation.pdf 过去几个月，随着核心功能工作放缓，收到的bug报告也变少了，我开始把注意力转向其他事情： - CI改进：自动化测试基础设施现已完全转为测试DKMS构建，这使其更快（充分利用我们的80核Arm64机器集群），并且还能够在发行版内核上自动化测试DKMS模块。这对于我们即将在短期内进入更多发行版至关重要——已有报告称在CachyOS上DKMS构建失败，而除了用户没有人捕获到这个问题，这真是个令人不快的意外。 - Rust：截至7.0版本，我检查过的所有主要发行版都已在内核中启用了CONFIG_RUST。这是一个历史性时刻 :) Bcachefs的用户空间代码已经转换到Rust，这项工作包括为核心btree迭代器API提供安全的Rust接口，以及相当多的工具代码。下一个版本将把这些绑定引入DKMS模块，我们将开始转换核心代码。最初的转换（已经准备好）将只是单元测试和性能测试，这样我们可以先在内核端以软依赖的方式推出Rust；我们需要在将其变为硬依赖之前验证能否部署包含C/Rust混合的DKMS模块。Rust意味着代码库将更不易出错、更稳定、更易于开发，也更便于吸引更年轻的工程师——现在学习C的人已经没那么多了！更棒的是，它打开了完整形式验证的可能性：由Rust处理内存安全后，其余部分在一个真正的生产代码库中变得易于处理。这正是我们想要的：文件系统中充满了各种不变量，目前依靠调试断言来检查，但在测试中真正执行这些调试断言需要大量的硬件和测试，并在CI前等待许多小时。一个完全形式验证的文件系统不可能一蹴而就，也不会在几年内实现，但能够开始对代码中真正需要形式验证的部分进行验证，将很快带来可靠性的真正提升，并让生活轻松许多。这将改变我们进行工程的方式。 - 性能工作：很高兴能抽出时间来做这个。我喜欢在没有干扰的时候做性能工作，可以暂时屏蔽其他一切；这需要花时间建立对整体情况的全面了解，准确找出问题所在以及值得优化的地方；运行各种微基准测试来突出不同瓶颈，在不同硬件上、不同文件系统下比较，无休止地分析剖析结果。瓶颈总是善于隐藏，一半的工作就是找出它们可能在哪里并使其可见。过程中发现了一些有趣的事情：一个有趣的发现——gcc对static_branch_unlikely()处理得不太好。静态分支是一种内核机制，通过运行时修补来启用或禁用分支，使其"免费"。不幸的是，gcc似乎不够聪明，无法将冷分支的主体放到函数末尾或者其他不会污染指令缓存的地方——因此跟踪和调试代码让我们付出了极其高昂的性能代价。这对调试代码来说很不幸，因为如果能将调试检查编译进内核但默认禁用，当用户怀疑有问题时可以在运行时启用而不需要调试构建，那将非常棒。唉，调试代码现在又回到了CONFIG_BCACHEFS_DEBUG后面。当我意识到这给我们造成了多少性能损失时，我骂了很多脏话。最终，基准测试和分析导致了200多个补丁，涵盖整个核心btree代码、日志和文件系统级别代码。核心事务提交的热路径现在只有4KB的机器码，btree代码有了一些避免锁竞争的新技巧，日志刷新路径现在完全无锁，还有更多——查看git历史获取完整列表：https://evilpiepirate.org/git/bcachefs-tools.git/log/ 单设备文件系统的性能现在看起来相当不错。在我测试的Epyc 9454上，48个Zen4核心，1.38.6在dbench 48客户端下达到了16.5 GB/秒——而XFS是16 GB/秒。一些性能补丁没有进入该版本（有些需要额外的测试/调试/设计工作，其他是一些小的磁盘格式变更，等待1.39版本）：有了这些补丁，bcachefs在dbench下可以达到**19 GB/秒**。使用fio测试4K随机写入，bcachefs在这个硬件上达到了**70万 IOPS**，而XFS是100万；两者都使用默认设置。在这种场景下，XFS只是通过预先布局的大文件将写入重新映射到底层块设备，而bcachefs则走完整的COW写入路径——数据校验、btree更新——每次写入都要执行。注意——达到这些数字需要btree分片正常工作；对于试图复现的人，这需要多个fio任务，每个fio进程自己创建数据文件，而不是通过主进程。但是——我也完全没有针对这个基准测试做任何优化，从剖析结果来看，仍然有改进的空间 :) 总有更多事情要做。未来几个月，我希望专门针对多设备文件系统做一些性能工作，一些用户在大阵列上仍然有性能问题，我已经有了一个需要修复的列表。 一如既往——加入IRC频道，参与进来；这是一个社区，而且仍在成长。而到了一定时候，我真的需要开始寻找年轻的工程师来教导——这是一个很有趣的项目，用户社区也非常好合作。如果你喜欢文件系统，并且认为自己有技能和奉献精神，欢迎加入。 干杯，Kent --- ## 1.38.6 - 性能发布 创作者头像 ## 1.38.6 - 性能发布 https://evilpiepirate.org/git/bcachefs-tools.git/tree/Changelog.mdwn 我想已经有一段时间没有写正式的公告了。唉，文件系统工程师/维护者/什么都做/无论现在你如何称呼我所做的事情，生活总是忙碌。 那么，来简单回顾一下： - 我们不再是实验性了。几个月前我就把网站上的实验标签去掉了——基于我惯常的判断："新收到的bug报告在减少，严重程度也大大降低，处理起来也比以前容易"。把这当作迟来的官方公告吧 :) - 对于那些新来的或错过了之前公告的人，回顾过去六个月的大新闻： reconcile（协调）和纠删码（erasure coding）。Reconcile极大地简化了设备和数据管理，它通过一个状态机引擎追踪所有数据的实际状态与期望状态之间的差异；它能响应选项和设备状态的变化，在后台移动数据，重新复制，应用选项变更（例如开启纠删码）。它被设计得很快；旋转设备上待处理的reconcile工作按物理LBA顺序索引，这意味着我们可以执行诸如"撤离"（evacuate）这样的技巧：在文件系统中的其他设备上找到被撤离设备上的所有数据副本，从而在所有设备之间并行执行撤离，且顺序十分规整。 - 纠删码：高性能且无写漏洞（write hole）。纠删码的实验标签已移除，它已投入使用且运行良好。Bcachefs的纠删码采用Reed/Solomon算法，与传统的RAID5/6完全相同，但没有写漏洞（不对现有条带进行原地更新）——并且不像ZFS，我们在不碎片化写入请求的情况下完成这一操作。条带是异步构建的，新写入的数据先被复制，当条带完成后这些额外副本就会被丢弃。分配器进行了优化，使得只要没有日志提交（即没有执行fsync操作），这些额外副本所在的bucket就能立即被重用（覆盖）。这意味着对于大块流式写入，额外副本只消耗总线带宽——它们在设备写缓存中时就会被覆盖。而且它与reconcile完全集成——开启纠删码选项后，它会在后台转换你的数据；如果设备发生故障，它会处理。 两者的文档都在用户手册中：https://bcachefs.org/bcachefs-principles-of-operation.pdf 过去几个月，随着核心功能工作放缓，收到的bug报告也变少了，我开始把注意力转向其他事情： - CI改进：自动化测试基础设施现已完全转为测试DKMS构建，这使其更快（充分利用我们的80核Arm64机器集群），并且还能够在发行版内核上自动化测试DKMS模块。这对于我们即将在短期内进入更多发行版至关重要——已有报告称在CachyOS上DKMS构建失败，而除了用户没有人捕获到这个问题，这真是个令人不快的意外。 - Rust：截至7.0版本，我检查过的所有主要发行版都已在内核中启用了CONFIG_RUST。这是一个历史性时刻 :) Bcachefs的用户空间代码已经转换到Rust，这项工作包括为核心btree迭代器API提供安全的Rust接口，以及相当多的工具代码。下一个版本将把这些绑定引入DKMS模块，我们将开始转换核心代码。最初的转换（已经准备好）将只是单元测试和性能测试，这样我们可以先在内核端以软依赖的方式推出Rust；我们需要在将其变为硬依赖之前验证能否部署包含C/Rust混合的DKMS模块。Rust意味着代码库将更不易出错、更稳定、更易于开发，也更便于吸引更年轻的工程师——现在学习C的人已经没那么多了！更棒的是，它打开了完整形式验证的可能性：由Rust处理内存安全后，其余部分在一个真正的生产代码库中变得易于处理。这正是我们想要的：文件系统中充满了各种不变量，目前依靠调试断言来检查，但在测试中真正执行这些调试断言需要大量的硬件和测试，并在CI前等待许多小时。一个完全形式验证的文件系统不可能一蹴而就，也不会在几年内实现，但能够开始对代码中真正需要形式验证的部分进行验证，将很快带来可靠性的真正提升，并让生活轻松许多。这将改变我们进行工程的方式。 - 性能工作：很高兴能抽出时间来做这个。我喜欢在没有干扰的时候做性能工作，可以暂时屏蔽其他一切；这需要花时间建立对整体情况的全面了解，准确找出问题所在以及值得优化的地方；运行各种微基准测试来突出不同瓶颈，在不同硬件上、不同文件系统下比较，无休止地分析剖析结果。瓶颈总是善于隐藏，一半的工作就是找出它们可能在哪里并使其可见。过程中发现了一些有趣的事情：一个有趣的发现——gcc对static_branch_unlikely()处理得不太好。静态分支是一种内核机制，通过运行时修补来启用或禁用分支，使其"免费"。不幸的是，gcc似乎不够聪明，无法将冷分支的主体放到函数末尾或者其他不会污染指令缓存的地方——因此跟踪和调试代码让我们付出了极其高昂的性能代价。这对调试代码来说很不幸，因为如果能将调试检查编译进内核但默认禁用，当用户怀疑有问题时可以在运行时启用而不需要调试构建，那将非常棒。唉，调试代码现在又回到了CONFIG_BCACHEFS_DEBUG后面。当我意识到这给我们造成了多少性能损失时，我骂了很多脏话。最终，基准测试和分析导致了200多个补丁，涵盖整个核心btree代码、日志和文件系统级别代码。核心事务提交的热路径现在只有4KB的机器码，btree代码有了一些避免锁竞争的新技巧，日志刷新路径现在完全无锁，还有更多——查看git历史获取完整列表：https://evilpiepirate.org/git/bcachefs-tools.git/log/ 单设备文件系统的性能现在看起来相当不错。在我测试的Epyc 9454上，48个Zen4核心，1.38.6在dbench 48客户端下达到了16.5 GB/秒——而XFS是16 GB/秒。一些性能补丁没有进入该版本（有些需要额外的测试/调试/设计工作，其他是一些小的磁盘格式变更，等待1.39版本）：有了这些补丁，bcachefs在dbench下可以达到**19 GB/秒**。使用fio测试4K随机写入，bcachefs在这个硬件上达到了**70万 IOPS**，而XFS是100万；两者都使用默认设置。在这种场景下，XFS只是通过预先布局的大文件将写入重新映射到底层块设备，而bcachefs则走完整的COW写入路径——数据校验、btree更新——每次写入都要执行。注意——达到这些数字需要btree分片正常工作；对于试图复现的人，这需要多个fio任务，每个fio进程自己创建数据文件，而不是通过主进程。但是——我也完全没有针对这个基准测试做任何优化，从剖析结果来看，仍然有改进的空间 :) 总有更多事情要做。未来几个月，我希望专门针对多设备文件系统做一些性能工作，一些用户在大阵列上仍然有性能问题，我已经有了一个需要修复的列表。 一如既往——加入IRC频道，参与进来；这是一个社区，而且仍在成长。而到了一定时候，我真的需要开始寻找年轻的工程师来教导——这是一个很有趣的项目，用户社区也非常好合作。如果你喜欢文件系统，并且认为自己有技能和奉献精神，欢迎加入。 干杯，Kent