Dlaczego cp --reflink = auto nie jest zachowaniem domyślnym?

Dlaczego cp --reflink=autozachowanie domyślne nie jest ? Czy może to spowodować jakąkolwiek szkodę, aby to umożliwić?

Czy można go włączyć w czasie kompilacji, aby był używany w całym systemie, nie tylko w interaktywnych powłokach?

Nie jest to ustawienie domyślne, ponieważ ze względu na niezawodność można chcieć wykonać kopię w celu ochrony przed uszkodzeniem danych. Również ze względu na wydajność możesz chcieć, aby zapisy miały miejsce w czasie kopiowania, a nie jakiś proces wrażliwy na opóźnienia, pracujący na pliku CoW i opóźniony przez zapisy na innej części dysku mechanicznego. Zauważ, że z coreutils v8.24 mv domyślnie odsyła link, ponieważ nie ma powyższych ograniczeń.

Nie wiem, dlaczego to nie jest domyślny, może dlatego, że zachowuje się tak samo jak innych narzędzi kopiujących ( rsync, cpio, pax, tar...), które nie mają wsparcia dla go (lub gdy pliki zostaną skopiowane całej interfejsu, który nie pozwala na to (jak NFS, samba, warstwy systemów plików bezpieczników ...).

Byłem w tej samej sytuacji kilka lat temu i patrząc szybko na kod GNU cp, wciąż jest tak samo, musisz załatać kod, aby uzyskać inne domyślne zachowanie:

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

Jednym z dużych problemów jest możliwość zabraknięcia miejsca na kopiowanie podczas pisania.

W przypadku normalnej kopii, gdy tylko kopia się zakończy, nigdy nie będziesz musiał się martwić, że zapis do istniejących części pliku nie powiedzie się: miejsce jest całkowicie przydzielone i nie zniknie, dopóki nie usuniesz pliku. Ale w przypadku kopii z odsyłaczem zawsze istnieje ryzyko, że w pewnym momencie tygodni lub miesięcy później zapis do istniejącej części pliku zakończy się niepowodzeniem, ponieważ nie ma wystarczającej ilości miejsca na kopię.

Odkrycie, że Twój system wykonywał kopie odnośników za twoimi plecami, gdy taka operacja nie powiodła się, byłoby dość paskudną niespodzianką.

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

ma lepszy sens niż łatanie kodu

1. Powody niezawodności, które mogą być potrzebne, aby wykonać kopię w celu ochrony przed „utratą” danych.

   Nie wiemy, z tego powodu, ale złe rzeczy, które mogą się zdarzyć, ograniczają się do zniszczenia mediów. Większość wszystkich urządzeń blokowych będzie miała jakąś formę identyfikacji uszkodzenia (CRC), jeśli nie przesyła korekcji błędów (parzystość).

2. Nie ze względu na wydajność.

   CoW dzieje się, gdy tylko część kasowania? blok jest zapisany do. Z nowoczesnym! Dyskiem! urządzenie rozmiar bloku sprzętowego jest wielokrotnością 4k. Zmiana części 4k powoduje, że dysk odczytuje cały 4k i zapisuje go ponownie, ale ponadto jądro zrobi to samo, więc nie dojdzie do częściowego zapisu do urządzenia blokowego, SSD lub w inny sposób . Jądro musi wykonać CoW z tych samych powodów, chyba że mamy buforowaną kopię, nie możemy stworzyć danych, które istnieją w innych częściach urządzenia, z wyjątkiem bajkowego końca pliku, ale wtedy chodzi o to, że sporny. Ale buforowanie kopii pliku i kopiowanie pliku to różne operacje, z których pierwsza jest znacznie tańsza.

   Adres zapisu jest nieistotny, ale należy wiedzieć, że „pewna nieużywana część urządzenia” jest tańsza do wykrycia niż „gdzie obecnie znajdują się bloki pliku”.

Faktem jest, że każda metoda CoW jest tańsza lub równa prostej aktualizacji urządzenia blokowego. Gdybyśmy nie rozmawiali o urządzeniach blokowych, byłaby to inna historia ... Zapisana gdzieś na taśmie.