Por que cp --reflink = auto não é o comportamento padrão?

Por que cp --reflink=autonão é o comportamento padrão? Poderia causar algum dano para ativá-lo?

É possível habilitá-lo em tempo de compilação, para que seja usado em todo o sistema, não apenas em shells interativos?

Não é o padrão, pois, por motivos de robustez, é possível que ocorra uma cópia para proteger contra corrupção de dados. Também por motivos de desempenho, convém que as gravações ocorram no momento da cópia, em vez de algum processo sensível à latência, trabalhando em um arquivo CoW e sendo atrasado pelas gravações, possivelmente em uma parte diferente de um disco mecânico. Observe que a partir do coreutils v8.24 mv irá refletir por padrão, pois não possui as restrições acima.

Não sei por que não é o padrão, talvez para que ele se comporta o mesmo que outros utilitários de cópia ( rsync, cpio, pax, tar...) que não têm suporte para ele (ou quando os arquivos são copiados através de uma interface que não permite que (como NFS, samba, camadas de sistemas de arquivos com fusíveis ...).

Eu estava na mesma situação há alguns anos e, olhando o código GNU cp rapidamente, ainda é o mesmo, você precisa corrigir o código para obter um comportamento padrão diferente:

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

Um grande problema é o potencial de ficar sem espaço para fazer a cópia quando você escreve.

Com uma cópia normal, assim que a cópia for concluída, você nunca precisará se preocupar com a falha na gravação de partes existentes do arquivo: o espaço é totalmente alocado e não desaparece até que você exclua o arquivo. Mas com uma cópia reflink, sempre existe o risco de que, em algum momento semanas ou meses adiante, uma gravação em uma parte existente do arquivo falhe porque não havia espaço suficiente para fazer uma cópia.

Descobrir que seu sistema estava fazendo cópias de refluxo nas suas costas quando uma operação como essa falhou seria uma surpresa bastante desagradável.

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

faz mais sentido do que corrigir o código

1. Razões de robustez que uma pessoa pode querer que uma cópia ocorra para proteger contra a "perda" de dados.

   Não sabemos o motivo, mas as coisas ruins que podem acontecer estão limitadas à destruição da mídia. A maioria dos dispositivos de bloco possui alguma forma de identificação de corrupção (CRC), se não encaminhar a correção de erros (paridade).

2. Não por razões de desempenho.

   CoW acontece quando apenas parte do? Apaga? bloco é gravado em. Com o moderno! Disk! dispositivo, o tamanho do bloco de hardware é múltiplo de 4k. Alterar parte do 4k faz com que a unidade leia todo o 4k e escreva-o novamente, mas além disso o kernel fará a mesma coisa, para que não haja gravações parciais atingindo o dispositivo de bloco, SSD ou outro . O kernel precisa executar o CoW pelos mesmos motivos, a menos que tenhamos uma cópia em cache, não podemos compor os dados que existem nas outras partes do dispositivo, exceto no final do conto de um arquivo, mas o ponto é discutível. Mas armazenar em cache uma cópia de um arquivo e copiá-lo são operações diferentes, o primeiro é muito mais barato.

   O endereço da redação é irrelevante, mas saiba que "uma parte não utilizada do dispositivo" é mais barata de descobrir do que "onde residem atualmente os blocos do arquivo".

O fato é que qualquer método CoW é mais barato ou igual a simplesmente atualizar um dispositivo de bloco. Agora, se não estivéssemos falando de dispositivos de bloco, seria outra história ... Escrita em fita em algum lugar.