Почему CP - reflink=auto не поведение по умолчанию?

Не знайте, почему это не значение по умолчанию, возможно так, чтобы это вело себя то же как другие утилиты копирования (rsync, cpio, pax, tar...), которые не имеют никакой поддержки его (или когда файлы копируются через интерфейс, который не признает что (как NFS, самба, слои файловых систем предохранителя...).

Я был в той же ситуации несколько лет назад и рассмотрении кода CP GNU быстро, это - все еще то же, необходимо исправить код для получения другого поведения по умолчанию:

--- 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;

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

имеет лучший смысл, чем исправление кода

Это не значение по умолчанию, поскольку из соображений надежности может потребоваться создание копии для защиты от повреждения данных. Также по соображениям производительности вы можете захотеть, чтобы запись происходила во время копирования, а не какой-то чувствительный к задержке процесс, работающий с файлом CoW и задерживаемый записью, возможно, в другую часть механического диска. Обратите внимание, что из coreutils v8.24 mv будет ссылаться по умолчанию, поскольку он не имеет вышеуказанных ограничений.

1. Для защиты от "потери" данных можно использовать копию.

   Мы не знаем, в чем причина, но плохие вещи, которые могут произойти, ограничиваются уничтожением носителей. Больше всего блочных устройств будет иметь некую форму идентификации повреждения (crc), если не пересылать исправление ошибки (паритет).

2. Не по причинам производительности.

   CoW происходит, когда записывается только часть блока ?erase? В современном устройстве !disk! размер аппаратного блока кратен 4k. Изменение части 4k приводит к тому, что диск считывает все 4k и записывает его снова, но вдобавок ко всему, ядро собирается сделать то же самое, так что не будет никакой частичной записи, достигающей блочного устройства, SSD или другого. Ядро должно выполнить CoW по тем же самым причинам, если у нас нет кэшированной копии, мы не сможем составить данные, которые существуют в других частях устройства, за исключением сказочной части файла, но в этом случае суть спорная. Но кэширование копии файла и копирование файла - это разные операции, первая стоит гораздо дешевле.

   Адрес записи несущественен, но следует знать, что "некоторая неиспользованная часть устройства" дешевле обнаружить, чем "где в настоящее время находятся блоки файла"

Факт, что любой метод CoW либо дешевле, либо равен простому обновлению блочного устройства. Если бы мы не говорили о блочных устройствах, то это была бы другая история... Написанная где-то на пленке.

Одна большая проблема заключается в том, что при записи может закончиться место для выполнения копии.

При обычном копировании, как только копирование завершается, вам никогда не нужно беспокоиться о том, что запись в существующие части файла не удастся: место полностью выделено и не исчезнет до тех пор, пока вы не удалите файл. Но при копировании со ссылкой всегда есть риск, что в какой-то момент, спустя недели или месяцы, запись в существующую часть файла будет неудачной, потому что не хватило места для создания копии.

Обнаружение того, что ваша система делала копии reflink за вашей спиной, когда такая операция завершилась неудачей, будет довольно неприятным сюрпризом.