Existem desvantagens em usar o mount --bind como um substituto para links simbólicos?

Os links simbólicos têm limitações em como funções como ls, mve cppodem operar neles porque, diferentemente dos comandos iniciados pelo shell cd, essas funções não possuem informações sobre como o usuário acessou o diretório em relação ao caminho lógico (consulte a publicação relacionada ). Parece que usar a mount --bindopção pode contornar isso, oferecendo maior funcionalidade e compatibilidade com o samba e outros servidores de arquivos, porque o diretório montado terá dois caminhos físicos independentes, em vez de um link.

Gostaria de substituir todos os meus links simbólicos por referências usando a mount --bindopção, mas isso significaria montar mais de 150 pontos no fstab. Existem problemas de desempenho que possam surgir dessa ou de outras desvantagens que devo considerar?

Com mount --bind, uma árvore de diretórios existe em dois (ou mais) locais na hierarquia de diretórios. Isso pode causar vários problemas. Os backups e outras cópias de arquivos selecionam todas as cópias. Torna-se difícil especificar que você deseja copiar um sistema de arquivos: você acabará copiando os arquivos montados em ligação duas vezes. Pesquisas com find, grep -r, locate, etc., irá percorrer todas as cópias, e assim por diante.

Você não obterá "maior funcionalidade e compatibilidade" com montagens de ligação. Eles se parecem com qualquer outro diretório, que na maioria das vezes não é um comportamento desejável. Por exemplo, o Samba expõe links simbólicos como diretórios por padrão; não há nada a ganhar com o uso de uma montagem de ligação. Por outro lado, montagens de ligação podem ser úteis para expor hierarquias de diretórios sobre o NFS.

Você não terá problemas de desempenho com montagens de ligação. O que você terá é dores de cabeça na administração. Montagens de ligação têm seus usos, como tornar uma árvore de diretórios acessível a partir de um chroot ou expor um diretório oculto por um ponto de montagem (geralmente é um uso temporário enquanto uma estrutura de diretórios está sendo remodelada). Não os use se não precisar.

Somente o root pode manipular montagens de ligação. Eles não podem ser movidos por meios comuns; eles bloqueiam sua localização e os diretórios ancestrais.

De um modo geral, se você passar um link simbólico para um comando, o comando atuará no próprio link, se ele operar em arquivos, e no destino do link, se ele operar no conteúdo do arquivo. Isso vale para diretórios também. Isso geralmente é a coisa certa. Alguns comandos têm opções para links simbólicos tratar de forma diferente, por exemplo ls -L, cp -d, rsync -l. Tudo o que você está tentando fazer, é muito mais provável que os links simbólicos sejam a ferramenta certa, do que as montagens de ligação sendo a ferramenta certa.

Além do que o @Gilles escreveu anteriormente, vale a pena notar que alguns utilitários podem considerar um diretório montado em ligação como um sistema de arquivos separado. Isso pode ter implicações de desempenho ou funcionalidade se o programa não puder mais assumir que o mesmo número de inode se refere ao mesmo arquivo (o que não ocorre, se estiverem em sistemas de arquivos diferentes), uma movimentação não pode ser otimizada como link-at- destino-depois-desvincular-fonte etc.

Você também deve usar montagens de ligação em vez de links simbólicos ao contar com um suporte que nem sempre pode estar no local (por exemplo, um disco externo) e se certificar de que a estrutura de diretórios original esteja no local, mesmo que o suporte falha ou é removido.

Por exemplo, se eu quiser manter / var / tmp em um cartão sd, usarei o mount mount, pois alguns programas esperam que / var / tmp seja um diretório válido, mesmo que o cartão seja removido.

Eu tentei o bind mount para solucionar um problema ao instalar alguns pacotes com pacman(archlinux, mais sobre isso aqui ) em um sistema em que /var(assim como /homee /usr/local) havia links simbólicos (nos sistemas de arquivos: SSD para SATA).

Parecia ótimo no início, mas, como Gilles apontou, locatesempre deu vários resultados para um único arquivo, apesar da PRUNE_BIND_MOUNTS = "yes"linha /etc/updatedb.conf.

$ locate \*/findutils-4.4.2 | xargs ls -ldiog
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /SHARED/LOCALS/Manjaro/src/findutils-4.4.2
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /usr/local/src/findutils-4.4.2

Indo um pouco mais adiante, descobri que montagens de ligação mais complexas podem ser removidas corretamente:

$ sudo mount --bind /SHARED/LOCALS/common/ /usr/local/common
$ findmnt | fgrep -n sdb
34:├─/SHARED/LOCALS                  /dev/sdb5           ext4           rw,relatime,data=ordered
35:│ └─/SHARED/LOCALS/Manjaro/common /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
36:├─/usr/local                      /dev/sdb5[/Manjaro] ext4            rw,relatime,data=ordered
37:│ └─/usr/local/common             /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
38:├─/SHARED/HOMES                   /dev/sdb4           ext4            rw,relatime,data=ordered
39:├─/home                           /dev/sdb4[/Manjaro] ext4            rw,relatime,data=ordered
40:├─/SHARED/VARS                    /dev/sdb3           ext4            rw,relatime,data=ordered
41:├─/var                            /dev/sdb3[/Manjaro] ext4            rw,relatime,data=ordered
42:└─/opt                            /dev/sdb5[/opt]     ext4            rw,relatime,data=ordered

$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
Rebuilding bind_mount_paths:
Matching bind_mount_paths:
Skipping `/SHARED/LOCALS/Manjaro/common': bind mount
Skipping `/usr/local/common': bind mount

$ locate \*/mmedia
/SHARED/LOCALS/common/mmedia

Sem a opção PRUNE_BIND_MOUNT, eu teria três resultados:

$ sudo sed -i '1 s/yes/no/' /etc/updatedb.conf 
$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
$ locate \*/mmedia
/SHARED/LOCALS/Manjaro/common/mmedia
/SHARED/LOCALS/common/mmedia
/usr/local/common/mmedia
$ sudo sed -i '1 s/no/yes/' /etc/updatedb.conf 

Outro problema com montagens de ligação:

• grub-mkrelpath produz caminhos incorretos se / boot for uma montagem de ligação

Obviamente, pode-se adicionar manualmente montagens de ligação (ponto de montanha ou destino) ao PRUNEPATHSin /etc/updatedb.conf.

Além disso, mountpointvários statcomandos ou funções podem ser usados ​​em ferramentas para melhorar a travessia do sistema de arquivos, conforme proposto aqui

Quando se trata de montagens de ligação de arquivo, elas se comportam mais perto de links físicos do que links simbólicos. Isso pode ter consequências um tanto sutis, por exemplo:

# echo 1 > 1.txt
# touch 2.txt
# mount --bind 1.txt 2.txt
# cat 2.txt
1
# echo 1a > 1.txt
# cat 2.txt
1a

Até agora tudo bem, mas agora considere quantos programas (editores, scripts escritos corretamente, etc.) realmente modificam arquivos:

# echo 1new > 1new.txt
# mv 1new.txt 1.txt
# cat 1.txt
1new
# cat 2.txt
1a

Se 2.txttivesse sido um link simbólico 1.txt, o último comando teria saída 1new, o que provavelmente seria esperado.

Isso pode causar alguns problemas sutis: na I systemd estava usando BindReadOnlyPaths=para fazer um determinado uso de serviço de um diferente resolv.confarquivo do que o resto do sistema, mas que acabou por ser esquisito no estranho e difícil de diagnosticar aspectos, porque resolvconfiria substituir o arquivo de origem por trás do serviço de volta.