Casos de uso para hardlinks? [fechadas]

Em que situações alguém desejaria usar um link físico em vez de um link virtual? Pessoalmente, nunca deparei com uma situação em que gostaria de usar um link físico em vez de um link flexível, e o único caso de uso que encontrei ao pesquisar na Web é a desduplicação de arquivos idênticos .

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

Uma coleção de mídia em que todos os arquivos são armazenados em um diretório simples e são classificados em outros diretórios com base em vários critérios, como ano, assunto, artista, gênero etc. Isso pode ser uma coleção pessoal de filmes ou um coletivo de estúdio comercial. trabalho. Essencialmente finalizado, o arquivo é salvo, provavelmente não será modificado e classificado, possivelmente em vários locais por links.

Lembre-se de que o conceito de "original" e "cópia" não é aplicável a links físicos: todo link para o arquivo é original, não existe "cópia" no sentido normal. 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 são vinculadas a esses arquivos. Os atributos do arquivo nos diretórios de classificação podem ser configurados para r / o, impedindo alterações acidentais nos nomes dos arquivos e na estrutura classificada, enquanto os atributos no diretório do catálogo podem ser r / w, permitindo que sejam modificados conforme necessário. (Isso pode ser um arquivo de música em que alguns players tentam renomear e reorganizar arquivos com base em tags incorporadas no arquivo de mídia, de entrada do usuário ou recuperação da Internet.) Além disso, como os atributos dos diretórios "copy" podem ser diferentes de No diretório "original", a estrutura classificada pode ser disponibilizada ao grupo ou mundo, com acesso restrito, enquanto o "catálogo" principal é acessível apenas ao usuário principal, com acesso total. Os arquivos em si, no entanto, sempre terão os mesmos atributos em todos os links para esse inode. (O ACL poderia ser explorado para melhorar isso, mas não minha área de conhecimento.)

Se o original for renomeado ou movido (o diretório "catálogo" único se torna muito grande para gerenciar, por exemplo), os links físicos permanecem válidos, os links flexíveis são quebrados. Se as "cópias" forem movidas e os links flexíveis forem relativos, os links flexíveis 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 há links flexíveis. Com links físicos, no entanto, parece consistente. Portanto, com 100 arquivos em um catálogo classificados em uma coleção de "tags", pode haver facilmente 500 "cópias" vinculadas. (Para uma coleção de fotografias, digamos data, fotógrafo e uma média de 3 tags "assunto".) O Dolphin, por exemplo, reportaria isso como 100 arquivos para links físicos e 600 arquivos se forem usados ​​links físicos. Curiosamente, ele relata o mesmo uso de espaço em disco de qualquer maneira, portanto parece uma grande coleção de arquivos pequenos para links flexíveis e uma pequena coleção de arquivos grandes para links físicos.

Uma ressalva para esse tipo de caso de uso é que, nos sistemas de arquivos que usam COW, modificar o "original" pode interromper os links físicos, mas não os links virtuais. Mas, se a intenção é obter a cópia principal, após editar, salvar e classificar, o COW não entra no cenário.

Links físicos são úteis para casos em que você não deseja vincular a existência dos dois arquivos. Considere isto:

touch a
ln -s a b
rm a

Agora bé inútil. (E essas etapas podem ocorrer bastante distantes, executadas por pessoas diferentes etc.)

Considerando que, com um link físico,

touch a
ln a b
rm a

b ainda está presente e correto.

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

$ 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 na fonte é decidido 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 envolvido.

Isso permite que o código (principalmente) idêntico não precise ser compilado para dois (principalmente) binários idênticos. Lembre-se de datas unix para os dias em que o espaço em disco era muito caro, embora, de acordo com Stevens no capítulo 4 do APUE, os links simbólicos tenham sido implementados no BSD4.2 (1983) para substituir várias limitações de links físicos. Um programa de teste para verificar se o nome do link simbólico é usado como o nome do programa pode se parecer com:

#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'
$ 

Quando o meu software P2P termina o download de um determinado arquivo, ele é colocado em um diretório específico. Os arquivos baixados quase nunca precisam ser editados. O caso mais comum é criar um hardlink em um diretório diferente, onde preciso que o arquivo esteja.

Vantagens:

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

O ponto principal: se eu soubesse com antecedência qual arquivo eu rmprimeiro, eu poderia usar o link simbólico. Mas eu nunca sei.

Os sistemas de arquivos são uma maneira simples e eficiente de organizar e classificar arquivos (esse é o principal motivo de sua existência). Os hardlinks permitem um maior grau de flexibilidade nesse assunto.

Como mencionado, não há conceito de original e 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, também não há hardlinks quebrados. .

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

1. Imagine que você tem uma coleção de filmes, músicas ou outras mídias e deseja aplicar critérios de classificação diferentes, como músicas classificadas por artista em um ramo (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 deseja duplicar os arquivos nem decidir onde colocar o "original" para ter a liberdade de reclassificar sem precisar " gerenciar "e vincular novamente os arquivos ao mover-se para evitar links quebrados.

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

3. Outro motivo muito importante, mas raramente mencionado, para a existência de links físicos são os ..subdiretórios. Na ..verdade, os diretórios são (na maioria das implementações do unix fs) links diretos para o diretório pai, sem links vinculados isso deve ser implementado de uma maneira completamente diferente, enquanto a existência de links vinculados facilita a implementação.

Exemplo muito comum do mundo real que precisa de links físicos:

git clone --reference <repository>

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

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

Há uma versão não-hard-link: git clone --shared <repository>. Isso, no entanto, é inconstante e tem muito mais ressalvas, pois todos estão trabalhando no mesmo diretório.

Recentemente, tive um caso de uso para um procedimento de atualização um tanto seguro para sistemas baseados em U-Boot, onde uImagehá um link para a imagem a ser inicializada; a idéia era que uma queda de energia não deveria causar problemas, não importa em que ponto do processo acontece (assumindo que o sistema de arquivos seja 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.

/editar:

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

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 rmestá aqui para poder escapar melhor de um estado estranho, por exemplo, se uImageé algo inesperado que causaria mvfalha [mas não necessariamente a ln -sfsolução anterior ].)

Um uso que tive para links físicos é ao baixar ou descompactar um arquivo quebrado. O programa que faz o download ou descompacta (como descompactar ou descompactar) 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 criar um link físico para ele.

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

Os arquivos são armazenados primeiro em uma árvore de diretórios "pool" com base em seu hash md5. Qualquer backup que use esse arquivo cria um vínculo físico com o arquivo do pool. À medida que os backups expiram / são excluídos, seus links físicos são removidos do sistema de arquivos.

Os links físicos são superiores aos links virtuais aqui porque eles fornecem contagem automática de referência. Um trabalho cron exclui periodicamente quaisquer arquivos no diretório do pool que não tenham mais de um link.

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

Outro caso de uso: o servidor de aplicativos da 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, ele resolve links simbólicos antes de tomar essa decisão.

Portanto, diga que deseja implantar uma compilação de aplicativo e atribua a ele um nome de arquivo descritivo (por exemplo, com um número ou data de lançamento). Você não pode fazer um link simbólico para o arquivo com o nome "real" - é necessário criar um link físico.

foo.warlinkado para foo-20170129.warnão funciona

foo.warcom links para foo-20170129.warobras.

Eu não gosto desse comportamento do tomcat, mas os hardlinks me dão uma maneira de contornar isso.