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

Question

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

É possível ativá-lo em tempo de compilação, por isso é usado em todo o sistema, não apenas em shells interativos?

    

Answer 1

Não é o padrão, pois, por motivos de robustez, pode-se desejar que uma cópia seja realizada para proteger contra corrupção de dados. Também por motivos de desempenho, você pode querer 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. Note que a partir do coreutils v8.24 mv irá fazer o "redink" por padrão, já que ele não tem as restrições acima.

    

Answer 2

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

Eu estava na mesma situação há alguns anos atrás, e olhando rapidamente para o código cp do GNU, 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;

    

Answer 3

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

faz mais sentido do que corrigir o código

    

Answer 4

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 de gravação em partes existentes do arquivo: o espaço é totalmente alocado e não desaparecerá até que você exclua o arquivo. Mas, com uma cópia em anexo, há sempre o risco de que, em algum momento, semanas ou meses, uma gravação em uma parte existente do arquivo falhe, porque não há espaço suficiente para fazer uma cópia.

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

    

Answer 5

1. Por razões de robustez, pode-se desejar que uma cópia seja realizada para proteger contra "perda" de dados.

   Não sabemos qual é o motivo, mas as coisas ruins que podem acontecer são limitadas à destruição de mídia. A maioria dos dispositivos de bloco terá alguma forma de identificação de corrupção (crc), se não corrigir a correção de erros (paridade).

2. Não por motivos de desempenho.

   CoW acontece quando apenas parte do "apagar"? bloco é escrito para. Com disco moderno! dispositivo o tamanho do bloco de hardware é um múltiplo de 4k. Mudar parte do 4k faz com que o drive leia todo o 4k e o escreva de novo, mas além disso o kernel vai fazer a mesma coisa, então não haverá gravações parciais atingindo o dispositivo de bloco, SSD ou outro . O kernel precisa executar o CoW pelas mesmas razões, a menos que tenhamos uma cópia em cache, não podemos inventar os dados que existem nas outras partes do dispositivo, salvar para o final do conto de um arquivo, mas, em seguida, o ponto é discutível. Mas o armazenamento em cache de uma cópia de um arquivo e a cópia de um arquivo são operações diferentes, o primeiro é muito mais barato.

   O endereço da escrita é irrelevante, mas faça com que se saiba que "alguma parte do dispositivo não utilizada" é mais barata de descobrir do que "onde os blocos do arquivo residem atualmente".

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, então seria outra história ... Escrita em fita em algum lugar.