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

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

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

它不是默认值，因为出于健壮性的原因，可能希望进行复制以防止数据损坏。同样出于性能原因，您可能希望写入在复制时进行，而不是在CoW文件上进行一些对延迟敏感的过程，并且由于写入而延迟到机械磁盘的不同部分，因此可能会延迟写入。请注意，默认情况下，从coreutils v8.24起，mv将进行重新链接，因为它没有上述约束。

不知道为什么它不是默认的，也许这样它的行为与其他复制实用程序（rsync，cpio，pax，tar...），其中有没有支持它（或当文件被通过接口复制的不允许（例如NFS，samba，保险丝文件系统层...）。

几年前我处在相同的情况下，快速查看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;

一个大问题是在编写时可能会用完空间来进行复制。

使用普通副本，然后在副本完成后，您就不必担心对文件现有部分的写入操作会失败：空间已完全分配，直到删除文件后才会消失。但是，使用reflink副本时，总会有几周或几个月的某个时间，由于没有足够的空间来制作副本，因此无法写入文件的现有部分。

发现您的系统在类似操作失败时在后台进行了reflink复制，这真是令人讨厌。

alias cp='cp --reflink=auto --sparse=always'

比修补代码更有意义

1. 出于健壮性的原因，人们可能希望进行复制以防止数据“丢失”。

   我们不知道这是原因，但是可能发生的坏事仅限于破坏媒体。如果没有前向纠错（奇偶校验），大多数所有块设备将具有某种形式的损坏识别（crc）。

2. 不是出于性能原因。

   仅当部分擦除时发生CoW吗？块被写入。随着现代！磁盘！设备的硬件块大小是4k的倍数。更改4k的一部分会导致驱动器读取整个4k并再次将其写入，但是最重要的是内核将执行相同的操作，因此不会有任何部分写入到达块设备，SSD或其他方式。出于同样的原因，内核需要执行CoW，除非我们有一个缓存的副本，否则我们不能组成设备其他部分中存在的数据，除非文件的结尾是事实，但关键是模拟。但是缓存文件副本和复制文件的操作有所不同，前者要便宜得多。

   这篇文章的地址无关紧要，但是要知道，发现“设备的某些未使用部分”要比“文件块当前所在的位置”便宜。

事实是，任何CoW方法要么便宜，要么等于简单地更新块设备。现在，如果我们不是在谈论块设备，那将是另一回事……写在磁带上的某个地方。