Чому cp --reflink = auto не є поведінкою за замовчуванням?

Чому це cp --reflink=autoне поведінка за замовчуванням? Чи може це завдати шкоди, щоб це дозволило?

Чи можна ввімкнути його під час компіляції, тому він використовується у всій системі, а не лише в інтерактивних оболонках?

Це не за замовчуванням, оскільки з міркувань надійності може бути потрібна копія для захисту від пошкодження даних. Також з міркувань продуктивності ви можете хотіти, щоб запис відбувався під час копіювання, а не якийсь процес, залежний від затримки, який працює над файлом 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;

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

З звичайною копією, як тільки копія завершиться, вам ніколи не доведеться турбуватися про те, що запис у існуючі частини файлу не вдається: простір повністю виділено і не вийде, поки ви не видалите файл. Але при копіюванні посилання, завжди існує ризик того, що в якийсь момент тижні чи місяці вниз дорога запису в існуючу частину файлу вийде з ладу, оскільки не було достатньо місця, щоб зробити копію.

Виявлення того, що ваша система робила копії для зворотної посилання за вашою спиною, коли така операція не вдалася, буде дуже неприємним сюрпризом.

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

має кращий сенс, ніж виправлення коду

1. Причини стійкості Ви можете хотіти, щоб копія мала місце для захисту від "втрати даних".

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

2. Не з міркувань продуктивності.

   Корова відбувається, коли стирається лише частина? блок записується в. З сучасним! Диском! Пристрій розмір апаратного блоку кратний 4 к. Зміна частини 4k змушує диск прочитати цілий 4k і виписати його знову, але поверх того, що ядро ​​буде робити те саме, щоб не було жодних часткових записів, що дістаються до блокового пристрою, SSD чи іншим чином . Ядро повинно виконувати CoW з тих же причин, якщо у нас є кешована копія, ми не можемо скласти дані, які існують в інших частинах пристрою, за винятком кінця файлу, але тоді справа в суперечка. Але кешування копії та копіювання файлу відрізняються різними операціями, перші коштують значно дешевше.

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

Справа в тому, що будь-який метод CoW є або дешевшим, або рівним простому оновленню блокового пристрою. Тепер, якщо ми не говорили про блокові пристрої, то це була б інша історія ... Написана десь на магнітофон.