在BTRFS文件系统上托管虚拟磁盘映像的原因

我已经阅读了一段时间有关BTRFS和ZFS的文章，尽管我很欣赏CoW在托管重要文件时的好处，但目前我对以下困境感到困惑：

考虑到ZFS和BTRFS在托管受随机写入影响的大文件（例如QCOW2，VDI等）时似乎都遭受性能下降，为什么有人会选择BTRFS作为托管VM的FS？

我知道在BTRFS的情况下，您可以使用chattr或nodatacow挂载选项有选择地关闭CoW，从而减少碎片和CoW造成的降级...

但是，根据Redhat所说，这也“禁用了数据和元数据的校验和验证，从而降低了数据完整性”。（除了压缩损失外，自然还有所需的CoW）。

基于此我问：为什么有人会选择BTRFS而不是说XFS over LVM over MD RAID？

如果主要用例是存储VM映像或数据库，并且您不愿意为了获得btrfs的数据完整性优势而接受潜在的性能问题，那么我想不出为什么要选择btrfs的任何原因通过xfs或ext4。

当存储VM映像只是文件系统的许多用途之一时，仅禁用VM映像目录的写时复制功能（使用chattr + C）非常重要。然后，对于该单个目录禁用写时复制非常方便，而对于其他文件系统，仍然保留了btrfs的所有优点。

BTRFS具有不同的磁盘格式，在某些写入模式下，它将优于其他文件系统。特别是，在改进将元数据写入磁盘的方式上花费了大量的精力，并且它支持一些高级功能，例如数据校验和，压缩和快照。对于大型文件，提高元数据性能通常并不重要。

与ZFS相比，BTRFS是更简单的解决方案，并且在Linux上得到更好的支持。主要缺点是（添加大量磁盘时）扩展性不佳，并且没有相同的功能集。

与XFS相比，它将是一种性能较低的解决方案。即，将更多的数据写入磁盘需要更多的处理器时间，并且最大吞吐量受到限制。通过执行禁用校验和验证之类的操作可以在某种程度上减轻这种情况，但是与BFS相比，BTRFS的主要好处是失去了XFS，后者是改进的元数据信息。即校验和和不同的日志记录（在某些情况下可能会更好）。

在写时复制（COW）支持方面，XFS优于严格的COW优先考虑性能。即，XFS在可伸缩性方面具有非常好的元数据和日志记录功能，并且通常不会在写入时覆盖文件数据，除非如果应用程序特别要求覆盖现有数据块，则它将允许覆盖现有磁盘块。在VM的情况下，这可能会很好，因为您的磁盘分配最初可能是连续的，在这种情况下，在VM的整个生命周期中都将保持连续。

使用BTRFS，即使如此，nodatacow您仍然可以通过行为手动创建数据快照CoW，因此它快速且不占用大量内存。此外，这些快照比使用LVM更灵活，因为您不需要在文件系统不知道的文件系统下保留空间，如果根本不需要，则不能使用它们。与ZFS一样，可以通过网络发送和接收快照，这可以帮助您改善备份策略。因此，即使使用nodatacowBTRFS似乎也比使用LVM优越。

在与云计算平台合作之后，我开始采用他们对虚拟机的看法，将其视为数据和功能的容器，而实际虚拟机的重要性并不高。

我宁愿拥有良好的备份-还原和安装-部署过程，而不必担心虚拟机的完整性，而更多地关注性能。

即通过MD突袭而不是BTRFS通过LVM选择JFS / XFS / EXT4。确保我永远不会存储任何未备份在虚拟机上的东西……并准备好脚本和过程以在合理的时间内备份​​新安装的虚拟机。

但这比其他任何事情更像是开发/实验场景。