Há algum perigo em usar mv (em vez de cp seguido por rm)?

6

Sou um estudante de pós-graduação com acesso a um grupo de pesquisa do grupo Linux na minha universidade. Ao longo dos anos, tenho acumulado muitos diretórios - eu acho que "pastas" é a terminologia do Windows / Mac? - no meu diretório pessoal ( ~ ). Quando estou trabalhando em uma nova simulação, crio um novo diretório no meu diretório pessoal usando mkdir e, em seguida, executo a simulação nesse diretório.

Mas, com o tempo, acumulei muitos desses diretórios no meu diretório pessoal. Agora quero mover alguns diretórios para o subdiretório. Por exemplo, talvez eu queira criar um novo diretório chamado simulations1_10 e, em seguida, mover os diretórios simulation1 , simulation2 , ..., simulation10 para esse diretório - para que a raiz do meu diretório inicial seja mais organizado.

Para fazer isso, eu poderia usar cp . Por exemplo:

cp -r simulation1/ simulations1_10/

copiaria o diretório simulation1 (e todo o seu conteúdo) para o diretório simulations1_10 . Eu poderia então remover simulation1 .

Mas, minhas transferências não estão ultrapassando os limites do sistema de arquivos, então mv é muito mais rápido que cp . ( mv , claro, também me permite evitar a etapa de remoção.) Por exemplo:

mv simulation1/ simulations1_10/

faz o truque rapidamente (e ao contrário de cp , mv é recursivo por padrão). De acordo com esta resposta para esta questão , mv é muito mais rápido porque" apenas atualiza o banco de dados inode em vários diretórios. "

Minha pergunta é: há algum perigo em usar mv ?

Eu acho que um perigo é que se mv for interrompido (devido a falta de energia, o usuário pressionando Ctrl + C , etc) durante uma transferência, o arquivo pode ficar corrompido na origem e no destino. Está correto?

Além disso, se eu usar mv muito , há uma chance de que o "banco de dados inode" seja atualizado com muita frequência, causando fragmentação de disco ou outros problemas no disco rígido?

    
por Andrew 30.03.2015 / 19:58

1 resposta

8

A função rename (que é a base do comando mv , "O utilitário mv deve executar ações equivalente à função rename () ") é atômico (veja POSIX link , que se refere ao padrão C):

This rename() function is equivalent for regular files to that defined by the ISO C standard. Its inclusion here expands that definition to include actions on directories and specifies behavior when the new parameter names a file that already exists. That specification requires that the action of the function be atomic.

(Mas veja isto para advertências: link .)

Operações interrompidas, seja por Ctrl-C ou de outra forma, nunca devem resultar em arquivos parcialmente transferidos. De fato, como você mencionou, um único sistema de arquivos mv na verdade não copia nenhum conteúdo de arquivo, apenas metadados de arquivo. O pior que deve acontecer nessa frente é ver os diretórios parcialmente movidos (se você usa mv a b c dest , é possível interromper e ter apenas, por exemplo, a movido para dest , mas todos arquivos e seus conteúdos terão sido movidos corretamente), arquivos regulares não parcialmente movidos.

Sobre a sua pergunta do lado do inode, eu diria que geralmente não é uma preocupação; atualizar inodes para mover apenas alguns diretórios é uma operação de rotina com pouca sobrecarga (as gravações de conteúdo de arquivo acontecendo no mesmo sistema de arquivos devem ser uma causa de impacto ou fragmentação de desempenho muito maior, dependendo do tipo de sistema de arquivos específico).

    
por 30.03.2015 / 20:05

Tags