Se eu mount --bind
/a
entrar /b
e se eu mv /a/bigfile /b/
levar muito tempo (se o arquivo de origem for grande). Na verdade, isso copiará o arquivo e excluirá o arquivo de origem em vez de simplesmente atualizar a tabela de arquivos do sistema de arquivos.
Eu entendo como e por que mount --bind
funciona. Conforme apontado por outros, existem algumas boas explicações sobre isso:
- O que é uma montagem vinculada?
- Por que não consigo criar um 'hardlink' para um arquivo de um diretório 'mount --bind' no mesmo sistema de arquivos?
Existe alguma maneira de dizer ao mount que a mount --bind
está no mesmo sistema de arquivos para que operações como esta (mover) sejam feitas atualizando a tabela de arquivos do sistema de arquivos?
Estou perguntando como resolver esse problema e não como entendê-lo: talvez um patch do kernel já disponível que eu não tenha conhecimento ou um parâmetro ausente que ainda não encontrei (etc).
Porquê: Na minha configuração atual existe um serviço (nextcloud) que suporta apenas o mount --bind
. Não posso usar links simbólicos. Se eu precisar, digamos, ter uma pasta compartilhada dentro de cada conta do nextcloud ela deve ser com bind. Posso aceitar qualquer solução que funcione com nextcloud se for feita no nível do sistema de arquivos/kernel. Isso ocorre porque a configuração atual também inclui acesso a esses arquivos de outras formas, como ssh. Em outras palavras, eu gostaria de poder mover um arquivo como no exemplo usando qualquer comando ou aplicativo.
Responder1
Aparentemente não, opágina de manualrename(2)
menciona isso:
EXDEV
caminho antigoenovo caminhonão estão no mesmo sistema de arquivos montado. (O Linux permite que um sistema de arquivos seja montado em vários pontos, masrename()
não funciona em diferentes pontos de montagem, mesmo que o mesmo sistema de arquivos esteja montado em ambos.
Se bem me lembro, uma montagem de ligação é o mesmo que montar o mesmo sistema de arquivos várias vezes, ou seja, não há "fonte" e "destino" para a ligação após o fato.
Há também outrorespondera outra pergunta sobre o mesmo assunto de alguns meses atrás. Esse aqui indica uma discussão sobre isso com os desenvolvedores do kernel. Então vá votar nisso.
Responder2
tenho o mesmo problema com nextcloud e samba em contêineres docker. resolvi isso movendo todos os dados para dentro do nextcloud e deixei que outros ligassem e montassem-nos a partir deste volume.
portanto, do ponto de vista de qualquer serviço, um mv está sempre dentro de apenas uma montagem de ligação.
não tenho certeza se isso ajuda você
Responder3
Usar rsync
em vez disso mv
deve resolver o problema. Tente usar o seguinte comando
rsync -avP /a/bigfile /b/bigfile
O problema é porque o ponto de vista mount --bind
está no kernel e está oculto em programas de nível superior como mv
. Ao contrário de mv
, rsync
move apenas as partes modificadas de um arquivo.
Isto explica sobremount --bind
O que é uma montagem vinculada?