renomear uma pasta enorme: é arriscado?

19

É arriscado renomear a pasta com 180 GB com o mvcomando?

Temos uma pasta /dataque contém 180 GB.

Queremos renomear a /datapasta para /BD_FILEScom o mvcomando

É seguro fazer isso?

— yael
fonte

14

Por que e como deve ser arriscado? Se não tiver certeza, ligue mvcom a -iopção

— dessert

5

Existe algo no seu ambiente que o leve a pensar que isso pode ser arriscado?

— Jeff Schaller

2

Você quer dizer se existe o risco de que o ato em si possa causar um problema ou se existe o risco de que haja efeitos problemáticos? Se você tem algum programa que espera que exista uma pasta / data, renomeá-la pode causar problemas.

— Acccumulation

3

Nota lateral: quase tudo é seguro se você tiver verificado os backups. Nada é tão seguro quanto deveria ser se você não o fizer. Em outras palavras: ao perguntar "é seguro", seu primeiro pensamento deve ser "verifiquei meus backups?"

— RedGrittyBrick

2

Quero dizer, o risco que poderia ser problemático ao mover uma pasta enorme com dados por esse sistema operacional, poderia interromper a movimentação no meio, por exemplo, ou perder dados

— yael

71

Alterar o nome em uma pasta é seguro, se permanecer no mesmo sistema de arquivos.

Se for um ponto de montagem ( /dataparece que poderia ser um ponto de montagem para mim, verifique isso com mount), você precisará fazer algo diferente de um simples, mvpois mv /data /BD_FILESmoveria os dados para a partição raiz (o que pode não ser o que você quer que aconteça).

Você deve desmontar o sistema de arquivos, renomear o diretório agora vazio, atualizar /etc/fstabcom o novo local para este sistema de arquivos e remontar o sistema de arquivos no local renomeado.

Em outras palavras,

umount /data
mv /data /BD_FILES(supondo que /BD_FILESainda não exista, nesse caso, remova-o primeiro)
atualização /etc/fstab, alterando o ponto de montagem de/data para/BD_FILES
mount /BD_FILES

Isso não envolve copiar nenhum arquivo, apenas altera o nome do diretório que atua como o ponto de montagem do sistema de arquivos.

Se a renomeação do diretório envolver movê-lo para um novo sistema de arquivos (o que seria o caso se estivesse /dataem um disco enquanto/BD_FILES estiver em outro disco, é uma coisa comum a fazer se você estiver movendo as coisas para uma partição maior, por exemplo) , Recomendo copiar os dados e deixar o original intacto até que você possa verificar se a cópia está correta. Você pode fazer isso com

rsync -a /data/ /BD_FILES/

por exemplo, mas veja o rsync manual para que isso faz e o que não faz (não preserva os links físicos, por exemplo).

Depois que a pasta é renomeada, você também precisa garantir que os procedimentos existentes (programas e usuários usando a pasta, backups etc.) estejam cientes da alteração de nome.

— Kusalananda
fonte

9

Existe o risco de que se espere mvapenas fazer uma renamechamada do sistema, mas devido a circunstâncias, ainda não se percebeu que copiará os arquivos e excluirá o original. Se eu precisar ter certeza absoluta de que apenas uma renamechamada do sistema é feita e mvnão fará algo "inteligente" nas minhas costas, abro um shell Python e o uso os.rename.

— precisa saber é

3

Com um kernel Linux relativamente recente, você pode mover o ponto de montagem:mkdir /BD_FILES && mount -M /data /BD_FILES && rmdir /data

— David Foerster

2

@ MichealJohnson Isso provavelmente funcionará em um sistema Linux, sim. O mais interessante rsyncé que é reinicializável.

— Kusalananda

3

@ MichealJohnson One usa as ferramentas que mais lhe agradam, obviamente. Sim, rsync -apreserva quase todos os metadados, mas não links físicos, ACLs ou atributos estendidos (adicione -HAXpara isso).

— Kusalananda

3

@Max Distribuições diferentes têm renamecomandos diferentes com comportamento diferente. Eu acho que isso é motivo suficiente para não usar o renamecomando quando você quer ter certeza do que ele fará.

— precisa saber é o seguinte

16

Você não está renomeando todos os arquivos no diretório, está renomeando um arquivo em /. Isso é porque:

diretórios são arquivos e
o sistema de arquivos realmente se preocupa com o inode, não com o texto real.

Portanto, renomear um diretório, não importa quantos arquivos ou quantos dados contenham, é trivial.

— RonJohn
fonte

14

Se você apenas renomear (origem e destino no mesmo sistema de arquivos), é simplesmente uma renomeação de uma entrada de diretório. Ele é bem-sucedido e o diretório tem um novo nome ou falha, caso em que nada muda ^* .

Se a origem e o destino estiverem em sistemas de arquivos diferentes, os dados precisarão ser copiados mv. Diferenças nos recursos do sistema de arquivos, como tamanho máximo do arquivo, limitações nos nomes dos arquivos, etc., podem causar problemas. Para evitar problemas, arquivos primeira cópia ( cp, rsync...) e após a cópia for concluída com êxito, remova os arquivos no local original.

_{* No entanto, existem alguns casos de canto, por exemplo mencionados na seção BUGS no man 2 rename}

— sebasth
fonte

> "É bem-sucedido e o diretório tem um novo nome ou falha, caso em que nada muda". Como é garantido? É verdade para todos os sistemas de arquivos? Existe alguma documentação sobre isso?

— turbanoff

Renomear é um único syscall, no entanto, há uma observação sobre o NFS na seção BUGS da renomeação do homem : renomear pode ter êxito mesmo quando o erro é retornado ao usar o NFS (veja detalhes na página do manual). Também adicionei uma nota na resposta. Não espero que nenhum sistema de arquivos no kernel considere aceitável uma entrada de diretório desaparecer caso um renomeamento falhe.

— sebasth

8

Como já foi dito, renomear uma pasta não representa um risco inerente ao conteúdo. Mas há um tipo diferente de risco que você pode querer considerar.

Procedimentos, scripts, atalhos definidos pelo usuário e configurações existentes que referenciam o local original podem ser interrompidos por essa alteração e, se os caminhos forem armazenados em um banco de dados, por exemplo, atualizá-los pode ser um grande trabalho.

Uma coisa que você pode fazer é criar um link simbólico para o novo nome de diretório, mas deixe o nome antigo no local por um tempo. Isso lhe dará tempo para avaliar o impacto dessa mudança. Você pode remover temporariamente o nome antigo, verificar se há algum problema e, se houver, recriar o nome antigo para que as pessoas possam continuar trabalhando enquanto você descobre o que precisa ser atualizado.

Um comando como este deve fazê-lo: ln -s /data /BD_FILES

— churrasco
fonte

4

Um risco mais leve que ninguém mencionou ainda é que, dependendo da sua estratégia de backup para essa pasta, isso pode levar a problemas de espaço em disco e latência na unidade de backup devido a 180 GB de dados "novos" aparecerem repentinamente e precisarem ser copiado.

— Kent

Eu prefiro algo assim mv thing1 thing2 ; ln --symbolic ./thing2 thing1. Dessa forma, tenho o novo nome e posso testar facilmente a ausência do antigo excluindo o link simbólico.

— Can-ned_food

3

Renomear é atômico. O único risco razoável é que mvdecida copiar tudo por algum motivo e que trava na metade. Se você tem GNU mv, mv -Tremoverá esse risco.

mv -Tinforma mvque está sendo movido para uma não-pasta; o que fará com que ele se recuse a fazer o mkdir()que, por sua vez, fará com que falhe se mover uma pasta e decidiu copiar por algum motivo.

Eu estava envolvido em sacudir bugs mv -Tenquanto trabalhava na minha tese de mestrado anos atrás. Costumava fazer a coisa errada em muitos casos extremos.

Por outro lado, você tem 180 GB de dados do usuário na partição raiz. Você provavelmente deseja remover isso da partição raiz.

— Joshua
fonte

Você não pode dizer apenas pelo nome se algo está na "partição raiz" ou não.

— Peter

@ Peter: Se não estiver na partição raiz, é um ponto de montagem. Você não pode renomear pontos de montagem montados com o comando mv.

— Joshua