Claro que sim. Se você executar, ln -s
criará um link simbólico, que é um inode apontando para um determinado objeto do sistema de arquivos, e é por isso que os links simbólicos podem atravessar os sistemas de arquivos e os links físicos não: os links físicos não têm seu próprio inode.
Se você montar um sistema de arquivos --bind
, criará um segundo ponto de montagem para um dispositivo ou sistema de arquivos.
Se você visualizar um link simbólico como um redirecionamento, visualize um --bind
sistema de arquivos montado como criando outro gateway para dados.
Symlinks e montagens de ligação são um jogo totalmente diferente.
A --bind
montagem parece um pouco mais robusta para mim e provavelmente é um pouco mais rápida do que trabalhar com um link simbólico. Por outro lado, não há desvantagens sérias no uso do link simbólico, pois o impacto no desempenho será pequeno (se houver).
Edit : Eu estive pensando sobre isso, e o impacto no desempenho pode ser um pouco maior do que eu pensava originalmente. Se você tiver um aplicativo que lê muitos arquivos diferentes, todos os novos arquivos abertos exigirão uma leitura extra. Algumas pesquisas aqui sugerem que minha suposição está correta; portanto, se você tiver um aplicativo pesado de E / S em execução lá, considere a --bind
opção de montar acima da solução de link simbólico.
O motivo pelo qual isso não é comum é provavelmente o fato de um link simbólico estar visível em um ls
, enquanto um mount de ligação é visível apenas quando se olha para / proc / mounts ou / etc / mtab (que é o que o comando mount faz, se for executado sem parâmetros). Fora isso, acho que não há problemas. Eu estaria interessado se houver, no entanto.
Além disso : outro problema ln -s
é que, para alguns aplicativos, quando o caminho é desreferenciado, o aplicativo pode ser recusado se "esperar" que determinados itens estejam em locais específicos.