Por que os links físicos são válidos apenas dentro do mesmo sistema de arquivos?

Estou lendo esta introdução à linha de comando de Mark Bates.

No primeiro capítulo, ele menciona que links físicos não podem abranger sistemas de arquivos.

Uma coisa importante a ser observada sobre os links físicos é que eles funcionam apenas no sistema de arquivos atual. Você não pode criar um link físico para um arquivo em um sistema de arquivos diferente. Para fazer isso, você precisa usar links simbólicos, Seção 1.4.3.

Eu sei apenas de um sistema de arquivos. Aquele que começa com root ( /). A afirmação de que links físicos não podem se estender por sistemas de arquivos não faz sentido para mim.

O artigo da Wikipedia sobre sistemas de arquivos Unix também não é útil.

Espero que eu possa responder de uma maneira que faça sentido para você. Um sistema de arquivos no Linux geralmente é composto de uma partição formatada de uma das várias maneiras (tem que escolher!) Em que você armazena seus arquivos. Seja seus arquivos de sistema ou pessoais ... todos eles são armazenados em um sistema de arquivos. Esta parte você parece entender.

Mas e se você particionar o disco rígido para ter mais de uma partição (pense em torta de maçã cortada em pedaços) ou adicionar um disco rígido adicional (talvez um pendrive?). Por uma questão de argumento, todos eles também têm sistemas de arquivos.

Quando você olha os arquivos no seu computador, vê uma representação visual dos dados no sistema de arquivos da sua partição. Cada nome de arquivo corresponde ao que é chamado de inode, que é onde seus dados, nos bastidores, realmente vivem. Um link físico permite que você tenha vários "nomes de arquivos" (por falta de uma descrição melhor) que apontam para o mesmo inode. Isso funciona apenas se esses links físicos estiverem no mesmo sistema de arquivos. Um link simbólico aponta para o "nome do arquivo", que é vinculado ao inode que contém seus dados. Perdoe minha arte bruta, mas espero que isso explique melhor.

image.jpg             image2.jpg
          \           /
           [your data]

aqui, image.jpg e image2.jpg apontam diretamente para seus dados. Ambos são hardlinks. Contudo...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

Neste exemplo (bruto), image2.jpg não aponta para seus dados, mas sim para image.jpg ... que é um link para seus dados.

Os links simbólicos podem funcionar além dos limites do sistema de arquivos (assumindo que o sistema de arquivos esteja conectado e montado, como o seu pendrive). No entanto, um link físico não pode. Ele não sabe nada sobre o que está no seu outro sistema de arquivos ou onde seus dados estão armazenados.

Espero que isso ajude a fazer melhor sentido.

O sistema de arquivos é composto por uma estrutura de diretório composta por entradas de diretório para organizar arquivos. Cada entrada de diretório associa um nome de arquivo a um inode .

Links flexíveis ( simbólicos ) são entradas de diretório que não contêm dados, apenas apontam para outra entrada (um arquivo ou diretório no mesmo sistema de arquivos ou outro sistema de arquivos). E quando você exclui o arquivo apontado, o link simbólico se torna inutilizável.

Links físicos são entradas de diretório que contêm o nome do arquivo e o número do inode . Quando você remove o último link físico, não pode mais acessar o arquivo.

Conclusão:

Como o inode é uma estrutura de dados usada para representar um objeto do sistema de arquivos, é interno ao sistema de arquivos e você não pode apontar para um inode de outro sistema de arquivos.

Portanto, os links físicos são válidos apenas no mesmo sistema de arquivos, mas os links virtuais (link simbólico) podem abranger os sistemas de arquivos, pois simplesmente apontam para outra entrada de diretório (a interface do sistema de arquivos e não um objeto interno).

O sistema de arquivos raiz pode ser composto de vários sistemas de arquivos; /usr/localpode estar montado em uma partição separada e /homeem outra partição em um disco em rede em outro lugar. Nesse caso, um link físico para /usr/local/bin/git(por exemplo) não pode ser criado fora de /usr/local, porque abrangeria sistemas de arquivos .

A razão para isso é que os inodes são alocados separadamente para ( e /, novamente, neste exemplo), e quando você cria um link físico, realmente cria um nome adicional para um inode./usr/local/home

Os links físicos têm o efeito de manter seu alvo vivo. Enquanto qualquer link físico estiver acessível, o sistema garantirá que seu destino não seja liberado. Portanto, é necessário que toda mídia que possa conter links físicos para um inode específico seja montada a qualquer momento que o sistema esteja tentando determinar se existem referências a ele.

Dado que a vida útil do inode é geralmente determinada pela manutenção de contagens de referência, em vez de varredura de referências, pode ser possível organizar coisas para que dois ou mais sistemas de arquivos que mantêm links entre si possam ser usados ​​independentemente, desde que não haja necessidade de usar links que entre os sistemas e desde que não houvesse necessidade de usar o fsck em nenhum deles. Se a contagem de inodes em um dos sistemas for perturbada, no entanto, a única maneira de tornar esse sistema útil novamente seria usar uma forma de operação fsck que poderia procurar referências nos dois sistemas de arquivos. Por causa dessa restrição, embora seja possível permitir que dois sistemas de arquivos interligados sejam utilizáveis ​​de forma independente, os benefícios de fazer isso provavelmente seriam muito limitados para fazer valer a pena.

Um único número de inode usado para representar o arquivo em cada sistema de arquivos. Todos os links físicos com base no número do inode. Link de referência do sistema de arquivos aqui .