☰

为什么 cp --reflink=auto 不是默认行为？

tag-icon • tag-icon btrfs coreutils
为什么 cp --reflink=auto 不是默认行为？

为什么cp --reflink=auto不是默认行为？启用它会造成任何伤害吗？

是否可以在编译时启用它，以便在整个系统中使用它，而不仅仅是在交互式 shell 中？

答案1

它不是 coreutils 9.0 之前的默认设置，因为这是一个重大更改。出于稳健性原因，人们可能希望进行复制以防止数据损坏。此外，出于性能原因，您可能希望写入发生在复制时，而不是在 CoW 文件上运行某些延迟敏感的进程，并可能因写入可能到机械磁盘的不同部分而延迟。请注意，从 coreutils v8.24 mv 开始，默认情况下将重新链接，因为它没有上述约束。由于 coreutils 9.0 cp 默认情况下会尝试重新链接，因此此类更改不适合次要版本。

答案2

rsync不知道为什么它不是默认的，也许它的行为与其他不支持它的复制实用程序（ ，，， ...）相同（或者当文件cpio通过不允许的界面复制时pax）tar（如 NFS、samba、fuse 文件系统层...）。

几年前我也遇到过同样的情况，快速查看 GNU cp 代码，它仍然是相同的，你必须修补代码以获得不同的默认行为：

--- coreutils-8.21/src/cp.c~    2013-06-22 21:50:26.265639114 +0100
+++ coreutils-8.21/src/cp.c     2013-06-22 21:51:06.880513924 +0100
@@ -775,7 +775,7 @@ cp_option_init (struct cp_options *x)
   x->interactive = I_UNSPECIFIED;
   x->move_mode = false;
   x->one_file_system = false;
-  x->reflink_mode = REFLINK_NEVER;
+  x->reflink_mode = REFLINK_AUTO;

   x->preserve_ownership = false;
   x->preserve_links = false;

答案3

从 coreutils 9.0 开始，reflink=auto 是默认行为。看：

https://lists.gnu.org/archive/html/info-gnu/2021-09/msg00010.html

这是为了发布 coreutils-9.0，一个稳定版本。

这是一个新的主要版本，具有以下重大变化：

  • cp 改变了它处理数据的方式
    • 默认启用 CoW（通过 FICLONE ioctl），
    • 在可用的情况下使用复制卸载（通过 copy_file_range），
    • 检测孔的方式不同（尽管 SEEK_HOLE）
    • 这也适用于 mv 和 install。

答案4

一个大问题是，当您写作时，可能会耗尽空间来进行复制。

使用普通副本，一旦复制完成，您永远不必担心对文件现有部分的写入失败：空间已完全分配，并且在删除文件之前不会消失。但对于重新链接副本，始终存在这样的风险：在几周或几个月后的某个时刻，对文件现有部分的写入将失败，因为没有足够的空间来制作副本。

当这样的操作失败时，发现你的系统在你背后做了重新链接复制，这将是一个非常令人讨厌的惊喜。

相关内容