Почему cp --reflink = auto не является поведением по умолчанию?

Почему cp --reflink=autoне поведение по умолчанию? Может ли это быть причиной какого-либо вреда?

Можно ли включить его во время компиляции, чтобы он использовался во всей системе, а не только в интерактивных оболочках?

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

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

Я был в той же ситуации несколько лет назад, и, глядя на 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'

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

1. Из соображений надежности может потребоваться копия для защиты от «потери» данных.

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

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

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

   Адрес написания не имеет значения, но нужно знать, что «какую-то неиспользуемую часть устройства» дешевле обнаружить, чем «где в данный момент находятся блоки файла».

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