btrfs的写副本特性对数据库应用程序(如postgresSQL)有何影响？

Question

我正在开发manjaro，它已经格式化为btrfs文件系统，并且它的写上复制特性仍然是默认的。刚才，我跟踪Arch wiki安装postgres，我注意到一些我不太理解的东西：

#https://wiki.archlinux.org/title/PostgreSQL

Warning:
If the database resides on a Btrfs file system, you should consider disabling Copy-on-Write for the directory before creating any database.

我在Google上搜索过，但我看到的似乎告诉我，COW会降低数据库的性能。但这是怎么发生的呢？牛应该减少I/O延迟，不是吗？

英语不是我的第一语言。可能有一些语法错误。请原谅我。

祝你们一切顺利。

Answer 1

如果您按照链接这里 > 这里终于来了，您可能会看到以下单词：

有些人坚持认为Btrfs是“在写上重定向”，而不是“在写上复制”，因为Btrfs是基于Ohad Rodeh基于重定向的B树更新的方案，并且因为使用这种思维方式更容易理解代码。

其结果是，复制写入写入新数据的其他地方，并留下一个重定向。这会导致磁盘上文件的碎片化。在这个答案中有一个关于它的讨论：https://unix.stackexchange.com/a/395013/20140

当您将它与postgresql的行为(像大多数现代DBMS一样)结合在一起时，结果是非常不可取的，因为postgresql会对非常大的文件进行大量的“随机”写入。btrfs将严重破坏这些文件。

更糟糕的是，postgresql已经非常优化了。它试图计划它的读取导致最少数量的磁盘查找。它还尝试在写入行时将收集到的表数据放在磁盘上的同一位置上。如果您在磁盘上将其文件碎片化，则会影响其收集读取并最终减缓其速度的能力。

在postgresql中，有一个名为真空的进程。真空的工作之一是设法保存同一张表的数据，这些数据粗略地收集在一起。如果你打开写拷贝，这个过程实际上会产生完全相反的效果，把数据广泛地传播到磁盘上。

我还会注意到，如果您使用的是非常快的SSD驱动器，碎片的成本已经有所降低，但仍然存在。

在磁存储方面，成本是巨大的。磁盘可以一次读取多MB与微观运动。但是如果数据是支离破碎的，磁盘头必须“寻找”到一个新的位置，这需要很长的时间(在计算方面)。