Como o linux funciona com links simbólicos?


11

Quero dizer, o que está acontecendo quando algum processo deseja ler um link simbólico? O que está acontecendo quando algo altera um link simbólico durante um processo de leitura ou gravação?

Por exemplo: Eu tenho 2 enormes, arquivos 100G semelhantes /mnt/1e /mnt/2. /mnt/1está disponível através do link simbólico /home/user/file. Algum programa Acomeça a ler /home/user/file. E depois de um tempo, algo muda o link de /mnt/1para /mnt/2, mas Aainda está lendo o arquivo.

O programa armazena em cache o caminho absoluto?

Irá falhar e erro, porque o link simbólico foi alterado ou funcionará bem, como se nada tivesse acontecido?

Será diferente caso /home/user/fileesteja vinculado a um dispositivo de bloco (por exemplo, 2 discos iscsi replicados)?

Respostas:


9

O link simbólico aponta para o nome do arquivo real ( inode ) no sistema de arquivos. Quando o sistema resolve esse link simbólico para localizar o arquivo real e abri-lo, ele localiza e usa o inode do arquivo. Nesse ponto, o caminho que você usou para chegar ao arquivo não importa. O que o sistema operacional não armazena em cache, ele lê o arquivo por seu inode. Pelo que entendi, você pode começar a ler o arquivo por meio de um link físico e removê-lo (desde que o arquivo ainda esteja vinculado de outro lugar) e isso não causará problemas desde que o arquivo tenha sido resolvido ( nome string-> inode).


4
Você pode remover TODOS os links do arquivo e continuar lendo-o quando o abrir. É por isso que você pode atualizar os pacotes sem reiniciar como no Windows; porque você pode rm o arquivo executável do programa mesmo que esteja em execução.
Psd #

11
@psusi Eu sei que os dados e o inode ainda estão lá e não apontam mais, mas depois que o arquivo é excluído, o sistema fica livre para substituir esse local no disco, certo? Portanto, se o arquivo for muito grande para caber no cache, como os arquivos de 100 GB em questão, o que acontecerá se parte deles for substituída antes de você chegar ao fim? Isso não é uma preocupação para arquivos críticos do sistema, porque eles são carregados no cache e mantidos lá, mas 100 GB é grande o suficiente para que eu possa pensar que isso possa ser uma preocupação.
22411 Kevin

2
Kevin, os arquivos não foram removidos do disco até o último processo que usa o arquivo morre. Você sempre pode encontrar todos os arquivos que estão em uso no momento no proc. Mas sua resposta parece ter explicado minha pergunta. Obrigado.
apressar

2
Esta resposta perde um ponto crítico, que um link simbólico contém o nome do arquivo de destino.
Keith Thompson

6

Um link simbólico é um pequeno arquivo que contém a localização (ou seja, caminho e nome do arquivo) de um arquivo de destino, com um sinalizador na entrada do diretório indicando que é um link simbólico.

Quando você abre um link simbólico, o sistema operacional segue o local para encontrar o arquivo de destino. Se o próprio destino for um link simbólico, ele segue sua localização (1) (2) até que o local aponte para um arquivo que não é um link simbólico (vamos chamá-lo de FinalFile ). Em seguida, o sistema operacional obtém o inode do FinalFile (o inode contém metadados como tempo de modificação e também possui um ponteiro para os dados do arquivo). Finalmente, o inode do FinalFile é aberto. A partir de agora, o processo usa esse inode para ler / gravar no arquivo. Como resultado, alterando o nome ou caminho do link simbólico, excluindo o link simbólico, alterando o caminho ou o nome do FinalFile ou mesmo excluindo o FinalFile(3) não tem efeito no processo; ainda está lendo do mesmo inode.

Na maioria dos casos, as operações de dados de arquivo no link simbólico afetarão o FinalFile (por exemplo, a leitura e gravação no link simbólico lerá / gravará no FinalFile ), mas há exceções: a readlink()chamada do sistema lê o conteúdo do link simbólico.

As operações de metadados de arquivo (como renomear ou excluir), por outro lado, geralmente afetam o link simbólico. Mas também há exceções aqui: a lstat()chamada do sistema é semelhante stat(), exceto pelo fato de retornar informações no próprio link simbólico, e não no FinalFile (2).


(1) Há um limite no número de níveis e as coisas ficam um pouco mais complexas se o local no link simbólico for um caminho relativo.

(2) Leia o link simbólico (7): manipulação simbólica de links para obter mais detalhes.man 7 symlink

(3) O rmcomando ou a unlink()chamada do sistema não remove fisicamente um arquivo. Ele remove a entrada de diretório que aponta para o inode do arquivo. O arquivo em si será removido apenas se ambos: a) não houver mais entradas de diretório (links físicos) que se refiram ao seu inode eb) nenhum processo tiver o arquivo aberto.


1

Isso é quase transparente para o Linux e está muito mais relacionado ao sistema de arquivos que você está usando do que ao sistema operacional.

Não é um arquivo regular ou muito pequeno porque você não pode criar um link simbólico ativo em uma partição VFAT, por exemplo, apenas copiando o próprio link simbólico para ele, porque é gravado diretamente pelo sistema de arquivos.

A diferença no link simbólico para um link físico é que o compromisso é para um link físico em vez de apontar para os setores de dados, como faz um link físico.

Exemplo:

Teste 1:

echo 'data' >file.txt

Isso criará o link físico file.txt apontando para os setores 10 a 20 * (* números apenas para explicar).

Teste 2:

Agora e se?

ln file.txt file_2.txt

Isso criou um arquivo_2.txt de link direto apontando para os setores 10 a 20 (o mesmo de arquivo.txt); portanto, se você excluir o arquivo.txt, os setores 10 a 20 ainda serão reservados e poderá ver dados dentro de arquivo_2.txt ... . (arquivo.txt e arquivo_2.txt são iguais aos originais)

Teste 3:

ln -s file.txt file_sym.txt 

O link simbólico apontou file_sym.txt para o link físico file.txt, portanto, ao tentar acessar file_sym.txt, você verá file.txt, mas se você excluir file.txt file_sym não encontrará mais o destino.

Esses são gerenciados pelo sistema de arquivos, por exemplo, pelos módulos ext4 para linux (ou se ele é compilado no kernel), não importa se você estiver usando Linux ou outro Unix.

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.