我正在考虑在数据库服务器的 raid 10 配置中实现 btrfs，但我对 nodatacow 选项感到困惑。
根据https://btrfs.wiki.kernel.org/index.php/Gotchas：
具有大量随机写入的文件可能会变得严重碎片化（超过 10000 个范围），导致 HDD 损坏，并在具有 SSD 或大量 RAM 的系统上导致 CPU 负载出现过多的多秒峰值。在服务器和工作站上，这会影响数据库和虚拟机映像。nodatacow 安装选项可能在这里有用，并有相关的陷阱。
然后文档指出nodatacow选项是：
不要为新创建的文件复制写入数据，现有文件不受影响。这也会关闭校验和！IOW，nodatacow 意味着 nodatasum。datacow 用于确保用户可以访问文件的旧版本或文件的新版本。datacow 确保我们永远不会将部分更新的文件写入磁盘。nodatacow 通过直接覆盖数据（如 ext[234]）提供轻微的性能提升，但代价是在系统故障时可能会部分更新文件。性能增益通常小于 5%，除非工作负载是随机写入大型数据库文件，这种情况下差异可能会变得非常大。注意：关闭压缩！
这是否意味着应该为数据库服务器中的磁盘选择此选项，并且使用此选项将禁用损坏校验和？
这是否意味着应该为数据库服务器中的磁盘选择此选项？
大概。数据库对文件系统施加的更改量将通过写时复制和校验和过程放大。[1][2] 即使正常的文件系统操作也会显着减慢活动数据库的速度，这就是为什么许多高性能 DBMS 支持原始磁盘进行存储的原因。[3][4][5]
使用此选项是否会禁用损坏校验和？
不幸的是，确实如此。[6]
[1] https://en.wikipedia.org/wiki/Copy-on-write#Copy-on-write_in_computer_storage
[2] https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
[3 ] https://lists.fedoraproject.org/pipermail/devel/2011-July/154251.html
[4] https://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for -oltp
[5] https://www.google.com/search?q=btrfs+virtual+machine
[6] https://btrfs.wiki.kernel.org/index.php/FAQ#Can_data_checksumming_be_turned_off.3F
| 归档时间： |
|
| 查看次数： |
6361 次 |
| 最近记录： |