Eu sei o que são links físicos, mas por que eu os usaria? Qual é a utilidade de um link físico?
Eu sei o que são links físicos, mas por que eu os usaria? Qual é a utilidade de um link físico?
Respostas:
A principal vantagem dos links físicos é que, comparados aos links flexíveis, não há penalidade de tamanho ou velocidade. Soft links são uma camada extra de indireção sobre o acesso normal a arquivos; o kernel precisa desreferenciar o link quando você abre o arquivo, e isso leva uma pequena quantidade de tempo. O link também ocupa uma pequena quantidade de espaço no disco, para conter o texto do link. Essas penalidades não existem com links físicos porque são incorporadas à própria estrutura do sistema de arquivos.
A melhor maneira que eu conheço de ver isso é:
$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../
A -iopção para lsfornecer o número de inode do arquivo. No sistema em que preparei o exemplo acima, eu estava em um diretório com o número de inode 1069765, mas o valor específico não importa. É apenas um valor único que identifica um arquivo / diretório específico.
O que isso diz é que, quando entramos em um subdiretório e observamos uma entrada diferente do sistema de arquivos chamada .., ela tem o mesmo número de inode que obtivemos antes. Isso não está acontecendo porque o shell está interpretando ..para você, como acontece com o MS-DOS e o Windows. No sistema de arquivos Unix, ..há uma entrada de diretório real; é um link físico que aponta para o diretório anterior.
Links físicos são os tendões que unem os diretórios do sistema de arquivos. Era uma vez, o Unix não tinha links físicos. Eles foram adicionados para transformar o sistema de arquivos simples original do Unix em um sistema de arquivos hierárquico.
(Para obter mais informações, consulte Por que '/' possui uma entrada '..'? )
Também é algo comum nos sistemas Unix que vários comandos diferentes sejam implementados pelo mesmo executável. Não parece mais o caso do Linux, mas dos sistemas que eu usei no passado cp, mve rmeram todos executáveis. Faz sentido se você pensar sobre isso: quando você move um arquivo entre volumes, é efetivamente uma cópia seguida por uma remoção, então mvjá era necessário implementar as funções dos outros dois comandos. O executável pode descobrir qual operação fornecer, porque recebe o nome pelo qual foi chamada.
Outro exemplo, comum em Linuxs embarcados, é o BusyBox , um único executável que implementa dezenas de comandos.
Devo salientar que na maioria dos sistemas de arquivos, os usuários não têm permissão para criar links físicos para diretórios. As entradas .e ..são gerenciadas automaticamente pelo código do sistema de arquivos, que normalmente faz parte do kernel. A restrição existe porque é possível causar sérios problemas no sistema de arquivos se você não tomar cuidado com a criação e o uso de links físicos de diretório. Essa é uma das muitas razões pelas quais existem links flexíveis; eles não correm o mesmo risco.
Um uso de hardlinks extremamente úteis é em backups incrementais combinados com o rsync. Economiza muito espaço e facilita muito o processo de restauração. Eu uso essa abordagem para backup em meus servidores.
Tire um tempo para ler esta explicação .
Se, depois de ler essa página da Wikipedia, sua pergunta for "por que eu os usaria", você não entenderá o que são links físicos.
Um link é uma entrada de diretório que aponta para blocos no disco. Em outras palavras, todos os arquivos no seu sistema possuem pelo menos um link. Quando você rmarquiva, é a chamada do sistema real unlink(). Remove a entrada do diretório. Os blocos no disco não foram alterados, mas o link se foi, portanto, o arquivo foi removido da lista de diretórios.
Você pessoalmente nunca pode usar links físicos, mas eles estão espalhados por todo o sistema. Por exemplo:
$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzip2
Você pode ver que bunzip2, bzcate bziptodos usam o mesmo inode. Em essência, é um arquivo com três nomes. Você poderia ter três cópias do arquivo, mas por quê? Usaria apenas espaço em disco desnecessariamente.
/bin, acho que essa é uma das fontes de confusão. Por que, às vezes, os executáveis seriam vinculados e, às vezes, vinculados?
Há vários usos. Eu os uso para criar bloqueios baseados em arquivo. A chamada do sistema de link (2) é atômica, diferente da maioria das outras chamadas do sistema.
Outro uso está no rsnapshot, onde os backups são feitos ao longo do tempo usando links físicos para reduzir a quantidade de espaço em disco. Se um arquivo não tiver sido alterado, ele será vinculado às instâncias mais antigas do arquivo, os arquivos que foram alterados serão copiados novamente.
Eu também os uso para trocar arquivos de configuração nos servidores:; rm file.cfg && ln ~/tmp/file.cfg file.cfgentão, os arquivos ~ / tmp / * podem ser excluídos com segurança.
lne em rmvez de apenas um mv?
Para adicionar às várias boas discussões já presentes ...
(inode, name)pares de formato fixo significa que não há nenhum custo extra no sistema de arquivos em ter links físicos (bem, desde que evitemos ciclos ao proibir o hardlinke de diretórios (exceto .e ..(isso começa a parecer cegueira para mais alguém?)))então nós os obtemos de graça.
Eu provavelmente deveria cobrir um cenário de armadilhas de links físicos. Um link físico será apenas o mesmo arquivo com um nome diferente e / ou um local diferente , desde que o arquivo vinculado original exista . Nem sequer é correto pensar no arquivo como "original": ambos são entradas de diretório por si só e ambos (ou mais) são iguais. Para arquivos de longa duração, isso pode ser uma bênção, mas se um dos pares for excluído e depois criado, mesmo com o mesmo nome e conteúdo, os arquivos serão separados.
Suponha que você criou um /foo/myfilelink físico para o link /repo/myfile. Ambos são ponteiros para os mesmos dados de arquivo; mudar um, o outro muda. Mas suponha que isso /repoocorra com um repositório Git. Se você fizer check-out de um ramo que não contém myfile, ele /repo/myfileserá excluído. Neste momento, /foo/myfiletorna-se uma cópia simples de /repo/myfile, como no momento em que o outro par foi desvinculado. É fácil nem perceber quando você alterna entre os ramos que o repertório de arquivo muda, mas, quando você faz o checkout do ramo original, um novo arquivo/repo/myfileé criado pelo Git. Se você não prestou atenção, se perguntaria por que os dois arquivos agora têm conteúdo diferente, embora seja fácil de entender, já que o relacionamento de vínculo físico entre os arquivos não tem idéia sobre seus nomes. Um link flexível, pelo contrário, sobreviveria por esse ciclo de exclusão e criação.
Por outro lado, o software que usa links físicos está ciente disso, e o Git é um excelente exemplo. O Git clona um repositório no mesmo sistema de arquivos quase de graça, porque usa links físicos por padrão em vez de copiar arquivos. Para o Git, o link físico é um caso de uso perfeito, porque seus arquivos de objeto e pacote nunca mudam; portanto, um clone do repositório nunca modifica o outro (o Git não sabe vincular arquivos modificáveis) e qualquer um dos clones pode ser excluído sem qualquer precaução: não há necessidade de rastrear qual é o "original" e realmente conter os arquivos: qualquer um dos links físicos é um parceiro igual e "contém" o arquivo completo. Soft links simplesmente não funcionariam aqui.
Outra vantagem do link físico é que qualquer link pode ser movido sem interromper o acesso ao conteúdo do arquivo. Com links flexíveis, mover o arquivo original faz com que todos os links flexíveis sejam danificados.
A conclusão é que, em muitos casos de uso, qualquer um dos tipos de links funciona igualmente bem, mas em alguns tipos é vantajoso. A eficiência, mencionada em muitas respostas aqui, provavelmente é uma preocupação muito pequena com máquinas e sistemas de arquivos modernos, a menos que você esteja limpando um sistema de arquivos em um chip FLASH de um controlador embutido insignificante. As diferenças funcionais são mais importantes e geralmente ditam as restrições de engenharia e a melhor escolha:
Além disso, devo salientar que a chamada de biblioteca que exclui um arquivo é chamada unlink()por um motivo! Cada entrada de diretório é apenas um link físico inicialmente singular para seu inode.