Quando a criação de um link físico seria útil?


11

Existem basicamente duas limitações principais com links físicos:

  1. Os links físicos normalmente exigem que o link e o arquivo residam no mesmo sistema de arquivos.
  2. Somente o superusuário pode criar um link físico para um diretório.

Assim, foram introduzidos links simbólicos para contornar as limitações dos links físicos. Então, a pergunta é: os links físicos ainda são necessários? Pode haver situações em que eles são mais úteis?


3
1) Links simbólicos não são seguidos por alguns servidores HTTP 2) Links físicos podem ser usados ​​para backups 3) Você pode compartilhar soquetes unix entre chroots 4) Você pode excluir qualquer versão de um link físico sem afetar os outros
Dietrich Epp

Esses servidores HTTP podem usar um hardlink que aponte para um link simbólico? , ou estou falando bobagem?
arana

Respostas:


11

Os hardlinks nos ajudam a organizar nosso sistema de arquivos de uma maneira muito mais flexível. Basicamente, os hardlinks nos permitem pegar um arquivo e ter vários locais no sistema de arquivos ao mesmo tempo. Pense em um cenário em que você é fotógrafo e tem muitas fotos (este é um exemplo da minha vida!). Você pode organizá-los pelas pessoas que aparecem neles, porque às vezes as pessoas pedem fotos delas. Mas você também pode organizá-los por local e data. Não há uma maneira real de aninhar essas três coisas, elas são eixos de organização totalmente separados. Assim, você pode criar três hierarquias diferentes para essas três coisas diferentes e ter cada foto presente nas três, semtendo que armazenar cada foto três vezes. Essa é a mágica dos hardlinks. Desvincule links simbólicos, não precisamos nos preocupar com a localização do "arquivo real", porque eles são todos os arquivos reais. Podemos excluir e mover à vontade, porque o arquivo será retido até que não haja mais referências a ele e removido quando você excluir o último hardlink. É simples e não exige que você acompanhe muito.


1
Ou pode-se ter um programa que se quer invocar pelos três nomes gzip, gunzipe zcat.
JdeBP

8

O conteúdo de um arquivo não será removido até que todos os links físicos (sim, todos os nomes de arquivos sejam links físicos, até o primeiro) tenham sido apagados e o arquivo fechado. Como tal, pode ser útil quando um arquivo é necessário em vários locais, mas pode ser removido de qualquer um a qualquer momento, por exemplo, entre ~/Downloads/coolsong.mp3e ~/Music/Cool Song.mp3.


3
Está correto. Eu o uso para continuar semeando um torrent enquanto tenho o arquivo nomeado corretamente na minha pasta de filmes limpos. É muito mais fácil do que mover e renomear arquivos que estão sendo propagados, e eu posso simplesmente excluir a pasta torrent quando terminar a propagação. É também assim que a Couch Potato faz isso.
Nicolas Bouliane 30/01

1

Uma vantagem não muito importante de um link físico sobre um link simbólico é que, quando atinge o inode para um link físico, o kernel não tem mais nenhum processamento para acessar o arquivo. Quando encontra um link simbólico, o kernel deve ler o valor do link e continuar percorrendo a estrutura de diretórios antes de chegar ao inode do arquivo. Isso leva mais tempo, embora a diferença não seja necessariamente facilmente mensurada. É realmente divertido quando um dos elementos no valor do link simbólico é ele próprio um link simbólico.


Ponto excelente. No Solaris, pode-se criar loops usando links simbólicos, cujo tratamento é ainda mais divertido :-)

1

existem várias razões para links físicos

  1. manter referências a um arquivo até a última referência (como Ignacio apontou)
  2. quando você vincula os arquivos, eles ocupam apenas o espaço de um arquivo no sistema de arquivos (as duas referências ao arquivo compartilham os mesmos nós-i). Portanto, os links físicos precisam estar no mesmo sistema de arquivos.

Portanto, uma razão para usar links físicos é possivelmente economizar muito espaço ...

Você pode anexar a qualquer uma das referências e os dados serão inseridos no arquivo compartilhado. Você também pode anexar a um descritor de arquivo enquanto lê pelo outro (por exemplo, com tail -f)


0

Muitos dos exemplos dados aqui são válidos, mas funcionariam igualmente bem com links flexíveis (por exemplo, o problema "preciso de um arquivo em vários locais").

Um bom exemplo de onde os links físicos são realmente úteis é o software de backup Dirvish :

O Dirvish é um sistema de backup de rede rotativo, rápido, baseado em disco.

Com o dirvish, você pode manter um conjunto de imagens completas de seus sistemas de arquivos com criação e expiração autônoma. Um cofre de backup sujo é como uma máquina do tempo para seus dados.

O Dirvish cria backups no nível do sistema de arquivos (ou seja, copia arquivos, não cria imagens), copiando arquivos para um sistema de arquivos (backup) separado (como um disco rígido USB). Cada vez que você faz um backup, o dirvish cria uma cópia completa e separada da árvore de diretórios a ser salva.

O truque é que, se o dirvish detectar que já existe uma cópia de backup mais antiga da árvore que você está salvando, reutilizará automaticamente os arquivos que não foram alterados, criando um link físico na nova árvore para o arquivo na árvore antiga.

Dessa forma, cada cópia de backup é uma cópia completa e independente da árvore de diretórios, mas, ao mesmo tempo, apenas os arquivos alterados ocupam espaço no sistema de arquivos. Em outras palavras, você obtém os benefícios de backups incrementais (economia de espaço) e backups completos (recuperação fácil) ao mesmo tempo.

Isso só é possível porque os links físicos são completamente transparentes às ferramentas do espaço do usuário.

Provavelmente, isso também funcionaria com links simbólicos (embora você tenha problemas ao fazer backup de dados que usam os links simbólicos), mas uma vantagem possível apenas com links físicos é:

Se você quiser jogar fora os backups antigos, basta excluir a árvore de diretórios de backup correspondente. Os arquivos vinculados somente a essa árvore são excluídos automaticamente pelo sistema de arquivos (porque seu último vínculo físico é excluído), mas os arquivos que também aparecem em outras cópias permanecem no disco.


Soa como rsnapshot.
Ignacio Vazquez-Abrams

0

Um caso útil é, digamos, quando você tem um programa (ou script) que precisa baixar um tarball temporário grande e após extraí-lo, seu programa o excluirá imediatamente.

Se, por algum motivo, você quiser preservar esse tarball para uso futuro, é a melhor maneira de fazê-lo ln /tmp/tarball.tgz ~enquanto o tarball ainda está sendo baixado. Então você não precisa fazer nada.

Quando o download terminar, e mesmo após o programa ter excluído o 'original', a cópia exata ainda deverá estar no diretório inicial.


0

Uso 'Hard Links' para fazer backup de alguns dos meus 'HowTos' e Snippets

Eu tenho um diretório chamado 'Documentos compartilhados' no meu usuário / raiz. Nesse diretório, tenho 'links físicos' para minhas dicas, truques, trechos, instruções que estão nos diretórios apropriados; php, mysql, css, regex, fórmulas, linux, etc., tê-los em 'um só lugar' facilita muito o uso, atualize-os do que ter que pular nos meus documentos / diretórios procurando esses documentos que uso com freqüência.

Há muito tempo, usei links simbólicos. Eu faria fielmente o backup desse diretório comum 'Documentos compartilhados' no meu servidor. O problema é que links simbólicos ou 'Soft Links', se copiados (cp-auv) ou tar'ed e copiados, APENAS faça backup ou copie o 'link' e NÃO o conteúdo do documento. Então, eu teria que percorrer os diretórios e copiar cada uma das duas dúzias de arquivos de sua localização real.

Com o HARD LINKS, eu posso copiar, tar, sincronizar o diretório 'Shared Docs' e fazer backup desses documentos amplamente dispersos com confiança; o conteúdo é realmente copiado. É realmente péssimo para mim, quando percebi que estava fazendo o backup de 0 arquivos de link e não da informação.

A desvantagem de usar 'Hard Links' é que fazer ls em um diretório não fornece uma indicação de que um arquivo está 'vinculado' a outro arquivo ou onde esse arquivo pode coexistir. Existem maneiras de encontrá-los, mas estou dizendo que não é óbvio com um simples ls -l -> aponta para ... Então, geralmente adiciono uma nota no início do documento indicando qual diretório / arquivos 'esse arquivo 'é' compartilhado 'com

Landis.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.