Is '--reflink = auto' seguro para definir como padrão para cp?

Question

Eu sou atualmente um usuário do BTRFS e gostaria de aproveitar a CoW de tal forma que quando arquivos são copiados no mesmo sistema de arquivos btrfs, eles são automaticamente desduplicados reutilizando a extensão existente. Existem duas maneiras em que posso pensar para fazer isso:

Solução um (local)

Eu poderia simplesmente definir um alias em meu .bashrc para que, sempre que eu chamar cp , ele anexe automaticamente o sinalizador --reflink=auto .

alias cp='cp --reflink=auto'

Solução dois (global)

A outra solução que consigo pensar seria criar /usr/local/bin/cp que tem uma precedência maior na variável PATH. O roteiro seria algo como:

#!/bin/sh

CP=/bin/cp

exec $CP --reflink=auto $*

Eu não acho que seria uma boa idéia substituir /bin/cp , pois atualizações de coreutils acabarão substituindo minhas alterações. Isso, no entanto, esperançosamente significaria que os aplicativos que chamam cp do PATH (em vez de diretamente através de /bin/cp ) sempre usarão automaticamente os reflexos.

Pergunta

Existe algum argumento contra isso, ou quaisquer situações em que isso tenha causado um problema? Eu suponho que se ele estiver definido como auto , ele determinará automaticamente se os sistemas de arquivos subjacentes suportam os reflexos e, se estiverem no mesmo dispositivo, use reflinks, o que significa que não haverá problema ao conectar um sistema de arquivos ext4 externo ou copiando entre os sistemas de arquivos btrfs?

Eu li Por que é cp --reflink = auto não é o comportamento padrão? e parece que o principal argumento é que o cp pode ser usado para criar um backup de um arquivo, mas então eu diria que, para mim, eu preferiria ser capaz de consumir menos espaço localmente e ter os dados duplicados para outra máquina completamente, onde pretendo fazer backup de dados. Nesse caso, seria implementada a solução 2 como segura?

Em termos de minimizar o uso do espaço em disco local, vi a sugestão de configurar --sparse=always , então suponho que uma pergunta semelhante se aplique a isso.

    

Answer 1

Observe que há um problema no seu código. Deixar $* sem aspas nunca faz sentido. $* é a concatenação dos parâmetros posicionais com o primeiro caractere de $IFS . E então, embora existam algumas variações no comportamento quando o IFS está vazio, isso está sujeito à divisão de palavras e geração de nome de arquivo. Aqui você quer:

#!/bin/sh -
exec /bin/cp --reflink=auto "$@"

"$@" expande para todos os parâmetros posicionais como argumentos separados.

Se você deseja atualizar /bin/cp e a alteração a ser preservada nas atualizações, a maioria dos sistemas terá uma maneira canônica de fazer isso. No Debian e nos derivados, você faria:

$ sudo dpkg-divert --local --rename /bin/cp
Adding 'local diversion of /bin/cp to /bin/cp.distrib'

Em seguida, escreva /bin/cp como:

#! /bin/sh -
exec "$0.distrib" --reflink=auto "$@"

Cada atualização de coreutils atualizará cp.distrib em vez de cp .

Observe que há uma implicação de desempenho na qual ele precisa carregar e executar sh antes de executar cp . Isso não é tão ruim no Debian, onde /bin/sh é baseado em dash .

Isso também significa que as mensagens de erro e as mensagens de ajuda mencionarão cp.distrib em vez de cp :

$ cp
/bin/cp.distrib: missing file operand
Try '/bin/cp.distrib --help' for more information.

Na última parte, você pode trabalhar escrevendo o script como:

#! /bin/bash -
exec -a "$0" "$0.distrib" --reflink=auto "$@"

(mesmo com ksh93 ou zsh , todos como bash de shells em comparação com dash ).

Ele não será estritamente equivalente, pois $0 conterá o caminho para esse script, em vez do argv[0] cp inicialmente recebido, mas pelo menos será algo como /bin/cp em vez de /bin/cp.distrib . / p>