Casos de uso para hardlinks? [fechadas]

Question

Em que situações alguém desejaria usar um link físico em vez de um link flexível? Eu pessoalmente nunca encontrei uma situação em que eu quisesse usar um link físico em um link flexível, e o único caso de uso que encontrei ao pesquisar na Web é deduplicação de arquivos idênticos .

    

Answer 1

Além do uso de backup mencionado em outro comentário, que, acredito, também inclui os instantâneos em um volume BTRFS, um caso de uso para links físicos sobre soft-links é uma coleção de arquivos com classificação de tags. (Não necessariamente o melhor método para criar uma coleção, um método baseado em banco de dados é potencialmente melhor, mas para uma coleção simples que é razoavelmente estável, não é tão ruim.)

Uma coleção de mídia em que todos os arquivos são armazenados em um único diretório e classificados em outros diretórios com base em vários critérios, por exemplo: ano, assunto, artista, gênero etc. Essa pode ser uma coleção de filmes pessoais ou obras coletivas do estúdio comercial. Essencialmente concluído, o arquivo é salvo, provavelmente não será modificado e classificado, possivelmente em vários locais por links.

Tenha em mente que o conceito de "original" e "cópia" não é aplicável a hard-links: cada link para o arquivo é um original, não há "cópia" no normal sentido. Para a descrição do caso de uso, no entanto, os termos imitam a lógica do comportamento.

O "original" é salvo no diretório "catálogo" e as "cópias" classificadas têm um link físico para esses arquivos. Os atributos de arquivo nos diretórios de classificação podem ser definidos como r / o, evitando quaisquer alterações acidentais nos nomes de arquivos e na estrutura classificada, enquanto os atributos no diretório de catálogo podem ser modificados para permitir que sejam modificados conforme necessário. (Nesse caso, haveria arquivos de música em que alguns players tentam renomear e reorganizar arquivos com base em tags incorporadas no arquivo de mídia, na entrada do usuário ou na recuperação da Internet.) Além disso, como os atributos dos diretórios "copy" podem ser diferentes No diretório "original", a estrutura ordenada pode ser disponibilizada para o grupo, ou mundo, com acesso restrito, enquanto o "catálogo" principal só é acessível ao usuário principal, com acesso total. Os próprios arquivos, no entanto, sempre terão os mesmos atributos em todos os links para esse inode. (ACL poderia ser explorada para melhorar isso, mas não minha área de conhecimento.)

Se o original for renomeado ou movido (o único diretório "catálogo" se torna muito grande para ser gerenciado, por exemplo), os hard-links permanecem válidos, os soft-links são quebrados. Se as "cópias" forem movidas e os soft-links forem relativos, os soft-links serão, novamente, quebrados e os hard-links não serão.

Nota: parece haver inconsistência em como as diferentes ferramentas relatam o uso do disco quando os soft-links estão envolvidos. Com hard-links, no entanto, parece consistente. Assim, com 100 arquivos em um catálogo classificados em uma coleção de "tags", poderia facilmente haver 500 "cópias" vinculadas. (Para uma coleção de fotos, digamos, data, fotógrafo e uma média de 3 tags "assunto".) O Dolphin, por exemplo, relataria isso como 100 arquivos para hard-links e 600 arquivos se soft-links forem usados. Curiosamente, ele relata que o mesmo uso de espaço em disco de qualquer maneira, por isso parece uma grande coleção de arquivos pequenos para soft-links, e uma pequena coleção de arquivos grandes para hard-links.

Uma ressalva para esse tipo de caso de uso é que nos sistemas de arquivos que usam COW, modificar o "original" pode quebrar os hard-links, mas não quebrar os soft-links. Mas, se a intenção é ter a cópia mestre, depois de editada, salva e classificada, a COW não entra no cenário.

    

Answer 2

Links físicos são úteis para casos em que você não deseja vincular a existência de ambos os arquivos. Considere isso:

touch a
ln -s a b
rm a

Agora b é inútil. (E estes passos podem acontecer bem distantes, ser feitos por pessoas diferentes, etc.)

Considerando que há um link físico

touch a
ln a b
rm a

b ainda está presente e correto.

    

Answer 3

Um único programa pode alterar seu comportamento dependendo de qual nome é lançado:

$ ls -li 'which pgrep' 'which pkill'
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Que em a fonte é decidida através de algo como

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

embora os detalhes exatos variem dependendo do sistema operacional e do idioma envolvidos.

Isso permite que (na maior parte) código idêntico não precise ser compilado para dois (na maior parte) binários idênticos. Tenha em mente as datas dos dias em que o espaço em disco era super caro, embora, de acordo com Stevens no capítulo 4 do APUE, links simbólicos foram implementados no BSD4.2 (1983) para substituir várias limitações de hardlinks. Um programa de teste para verificar se o nome do symlink é usado como o nome do programa pode ser algo como:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

E testado via:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

    

Answer 4

Quando meu software P2P termina o download de um determinado arquivo, o arquivo é colocado em um diretório específico. Arquivos baixados dificilmente precisam ser editados. O caso comum é que eu faço um hardlink em um diretório diferente onde eu preciso que o arquivo seja.

Vantagens:

• Ainda compartilho o arquivo na rede P2P como deveria, mesmo se eu rm ou mv a "cópia".
• O arquivo também está no caminho em que preciso dele; a maioria desses locais não é compartilhada.
• Eu posso rm o "original" parar de compartilhar o arquivo; esta operação não afeta a "cópia" no lugar desejado.
• Meu espaço em disco é usado apenas uma vez.

O ponto principal: se eu soubesse com antecedência qual arquivo eu iria rm , eu poderia usar o symlink. Mas eu nunca sei.

    

Answer 5

Sistemas de arquivos são uma maneira simples e eficiente de organizar e classificar arquivos (essa é a principal razão de existência deles). Os hardlinks permitem um maior grau de flexibilidade nesta questão.

Como mencionado, não há conceito de original e de cópias ao lidar com hardlinks, todas as entradas de diretório (hardlinks) são simplesmente referências à existência do arquivo (aponte para seu inode) sem precedência, portanto não há hardlinks ...

Portanto, aqui estão alguns dos casos de uso que os hardlinks acessam , mas os softlinks não :

1. Imagine que você tenha uma coleção de filmes, músicas ou outras mídias e queira aplicar diferentes critérios de classificação, como músicas classificadas por artista em uma filial (cada artista tem seu próprio subdiretório); por gênero em outro ramo (cada um em um subdiretório diferente), etc. Ainda assim você não quer duplicar os arquivos nem decidir onde colocar o "original" para que você tenha a liberdade de reclassificar sem precisar " gerenciar "e re-linkar arquivos ao mover para evitar links quebrados.

2. Outro motivo é evitar o desperdício de espaço de armazenamento que seria necessário para ter várias cópias do mesmo arquivo e ainda permitir que o chroot syscall se beneficie de um subconjunto de arquivos na raiz do sistema de arquivos "principal" (links simbólicos nunca poderiam referenciar arquivos de fora da sandbox chroot , mesmo se eles tivessem caminhos relativos).

3. Outra razão muito importante, mas raramente mencionada, para os hardlinks existirem são os subdiretórios .. . Os diretórios .. na verdade são (na maioria dos implementos unix fs) hardlinks para o diretório pai, sem hardlinks, isso tem que ser implementado de uma maneira completamente diferente, enquanto a existência de hardlinks torna isso muito fácil de ser implementado.

Answer 6

Exemplo muito comum no mundo real que precisa de links de hardware:

git clone --reference <repository>

Isso clona de um repositório local do Git com quase zero de cópia. Em vez de copiar os arquivos objeto (arquivos imutáveis usados pelo Git para seu "banco de dados"), eles simplesmente os vinculam.

Qualquer repo pode remover um objeto, mas o inode permanece válido pelo restante dos repos. E se um objeto for removido de todos os repos, ele será excluído do disco. Os hard links criam uma solução robusta e rápida. Muito comum em servidores de IC.

Existe uma versão não vinculativa: git clone --shared <repository> . Isso, no entanto, é instável e tem muitas outras ressalvas, já que todos estão trabalhando no mesmo diretório.

    

Answer 7

Recentemente, usei um caso de uso para um procedimento de atualização um pouco seguro para sistemas baseados em U-Boot em que uImage é um link físico apontando para a imagem a ser inicializada, a ideia era que uma queda de energia não causasse problemas, importa em que ponto do processo isso acontece (assumindo que o sistema de arquivos é reproduzido):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Sem hardlinks, não seria tão simples assim.

/ edit:

Graças aos comentários, agora sei que seria melhor fazer isso:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(O rm está aqui para poder escapar melhor de um estado estranho, por exemplo, se uImage for algo inesperado, o que tornaria mv a falhar [mas não necessariamente a anterior ln -sf solution].)

    

Answer 8

Um uso que eu tive para hard links é quando estou baixando ou descompactando um arquivo quebrado. O programa que faz o download ou descompacta (como descompactar ou unrar) geralmente remove automaticamente o arquivo incompleto quando encontra um erro, e geralmente não há opção para mantê-lo. Se eu quiser manter o arquivo, posso fazer um link para ele.

    

Answer 9

BackupPC é um sistema de backup que usa links físicos nos servidores para fornecer desduplicação em nível de arquivo.

Os arquivos são armazenados primeiro em uma árvore de diretórios "pool" com base no hash md5. Qualquer backup que faça uso desse arquivo faz um link físico para o arquivo do pool. Conforme os backups expiram / são excluídos, seus links físicos são removidos do sistema de arquivos.

Os hard links são superiores aos soft links aqui porque fornecem contagem automática de referência. Um cron job exclui periodicamente todos os arquivos no diretório do pool que não possuem mais de um link.

Esse método tem algumas desvantagens (principalmente, é difícil usar ferramentas baseadas em sistema de arquivos para replicar o armazenamento de backup), mas está provado que é bastante robusto na prática.

Outro caso de uso: o servidor de aplicativos web tomcat java trata nomes de arquivos como metadados. Um arquivo java "war" deve ser nomeado com base em seu caminho no servidor da web.

por exemplo: foo.war é o código java que serve o URL /foo

Infelizmente, resolve links simbólicos antes de tomar essa decisão.

Então, digamos que você queira implantar uma compilação de aplicativo e fornecer um nome de arquivo descritivo (por exemplo, com um número de release ou uma data). Você não pode criar um link simbólico para o arquivo com o nome "real" - você precisa criar um link físico.

foo.war symlinked para foo-20170129.war não funciona

foo.war foi vinculado a foo-20170129.war works.

Eu não gosto deste comportamento do gato, mas os hardlinks me dão um jeito de contornar isso.