Quantas vezes o disco é acessado?

Fundo

Digamos que temos a seguinte configuração de diretório:

$ ll
total 0
-rw-r--r-- 2 root root 0 Jul 29 23:36 afile.txt
-rw-r--r-- 2 root root 0 Jul 29 23:36 hL
lrwxrwxrwx 1 root root 9 Jul 30 01:22 sL -> afile.txt

Agora vamos analisar suas 2 perguntas.

Perguntas

1. Se for fornecido um hard link /hL, apontando para o inode do arquivo acima, em que ordem o disco é acessado?

Com hardlinks, eles possuem a mesma referência de inode que o arquivo/diretório original para o qual estão apontando. Portanto, não há acesso HDD adicional para lê-los.

Por exemplo:

$ stat hL | head -3
  File: ‘hL’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d    Inode: 667668      Links: 2

vs.

$ stat afile.txt | head -3
  File: ‘afile.txt’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d    Inode: 667668      Links: 2

A única diferença entre esses 2 é o nome. Portanto, qualquer caminho incorrerá no mesmo número de acessos ao HDD.

2. Se for fornecido um soft link /sL, apontando para o arquivo acima, em que ordem o disco é acessado?

No entanto, com links suaves, há um acesso adicional ao HDD. Esse acesso adicional seria contra os metadados do diretório, onde o arquivo sLreside. Isso retornaria detalhes informando que esse arquivo é de fato um link simbólico e está apontando para outro arquivo/diretório.

Por exemplo:

$ stat sL | head -3
  File: ‘sL’ -> ‘afile.txt’
  Size: 9           Blocks: 0          IO Block: 4096   symbolic link
Device: fd00h/64768d    Inode: 681295      Links: 1

Aqui podemos ver que é do tipo 'link simbólico' e está apontando para afile.txt. Observe também que ele tem um inode diferente (681295 vs. 667668), mais uma prova de que vai custar uma leitura adicional.

Então, quais são as ordens de leitura?

Se você usar straceo próprio shell Bash, onde está executando comandos nesses arquivos/diretórios, poderá ter uma ideia de como as coisas funcionam.

[pid 18098] stat("/tmp/adir/hL", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 18098] open("/tmp/adir/hL", O_RDONLY) = 3
[pid 18098] fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0

Aqui está a saída do comando more /tmp/adir/hL.

Para /tmp/adir/hL:

• stat/open (/) → stat/open (tmp) → stat/open (adir) → stat/open (hL)

Para /tmp/adir/sL:

• stat/open (/) → stat/open (tmp) → stat/open (adir) → stat/open (sL) → stat/open (afile.txt)

Detalhes adicionais

A página da Wikipedia sobre links simbólicos também escapa a tudo isso:

Embora armazenar o valor do link dentro do inode salve um bloco de disco e uma leitura de disco, o sistema operacional ainda precisa analisar o nome do caminho no link, o que sempre requer a leitura de inodes adicionais e geralmente requer a leitura de outros e potencialmente muitos diretórios, processamento tanto a lista de arquivos quanto os inodes de cada um deles até encontrar uma correspondência com os componentes do caminho do link. Somente quando um link aponta para um arquivo no mesmo diretório, os "links simbólicos rápidos" fornecem um desempenho significativamente melhor do que outros links simbólicos.

Referências

• Links Simbólicos - Wikipedia

Ambas as perguntas feitas são de fato a pergunta: "Como path_resolutionfunciona?", então basta olhar para todo o processo desse ponto de vista.

De PATH_RESOLUTION(7) lemos:

Um nome de arquivo (ou nome de caminho) é resolvido da seguinte maneira.

E depois vemos que o primeiro passo é comum tanto para hardlinks quanto para links simbólicos (onde o sistema decide qual é o ponto inicial da resolução do caminho: diretório raiz /, diretório chroot ou diretório atual).

Se o nome do caminho começar com o caractere '/', o diretório de pesquisa inicial será o diretório raiz do processo de chamada. (Um processo herda seu diretório raiz de seu pai. Normalmente este será o diretório raiz da hierarquia de arquivos. Um processo pode obter um diretório raiz diferente usando a chamada de sistema chroot(2). Um processo pode obter uma montagem totalmente privada namespace caso ele—ou um de seus ancestrais—foi iniciado por uma invocação da chamada de sistema clone(2) que tinha o sinalizador CLONE_NEWNS definido.) Isso manipula a parte '/' do nome do caminho.

Se o nome do caminho não iniciar com o caractere '/', o diretório de pesquisa inicial do processo de resolução será o diretório de trabalho atual do processo. (Isso também é herdado do pai. Pode ser alterado pelo uso da chamada de sistema chdir(2).)

Os nomes de caminho que começam com um caractere '/' são chamados de nomes de caminho absolutos. Os nomes de caminho que não começam com '/' são chamados de nomes de caminho relativos.

Como não vemos diferença no ponto de partida entre links físicos e simbólicos. Mas, uma diferença aparece no próximo passo quando a caminhada começa:

Defina o diretório de pesquisa atual para o diretório de pesquisa inicial. Agora, para cada componente não final do nome do caminho, onde um componente é uma substring delimitada por caracteres '/', esse componente é pesquisado no diretório de pesquisa atual.

Se o processo não tiver permissão de pesquisa no diretório de pesquisa atual, um erro EACCES será retornado ("Permissão negada").

Se o componente não for encontrado, um erro ENOENT será retornado ("No such file or directory"). Se o componente for encontrado, mas não for um diretório nem um link simbólico, um erro ENOTDIR será retornado ("Não é um diretório").

Se o componente for encontrado e for um diretório, definimos o diretório de pesquisa atual para esse diretório e vamos para o próximo componente.

Como a descrição indica, não há diferença na resolução do caminho para arquivos e links físicos - o processo é o mesmo. E os links simbólicos? Lemos mais:

Se o componente for encontrado e for um link simbólico (symlink), primeiro resolvemos esse link simbólico (com o diretório de pesquisa atual como diretório de pesquisa inicial). Em caso de erro, esse erro é retornado. Se o resultado não for um diretório, um erro ENOTDIR será retornado. Se a resolução do link simbólico for bem-sucedida e retornar um diretório, definimos o diretório de pesquisa atual para esse diretório e vamos para o próximo componente. Observe que o processo de resolução aqui pode envolver recursão se o componente de prefixo ('dirname') de um nome de caminho contiver um nome de arquivo que seja um link simbólico que resolva para um diretório (onde o componente de prefixo desse diretório pode conter um link simbólico e, portanto, sobre). Para proteger o kernel contra estouro de pilha, e também para proteger contra negação de serviço, há limites na profundidade máxima de recursão e no número máximo de links simbólicos seguidos. Um erro ELOOP é retornado quando o máximo é excedido ("Muitos níveis de links simbólicos").

Como indicado acima, a resolução de links simbólicos requer operações adicionais de acesso ao disco, respondendo às duas perguntas:

Se for fornecido um hard link /hL, apontando para o inode do arquivo acima, em que ordem o disco é acessado?

e

Se for fornecido um soft link /sL, apontando para o arquivo acima, em que ordem o disco é acessado?

podemos concluir que o acesso por hardlinks não difere do acesso comum a arquivos, mas a resolução de links simbólicos requer operações adicionais de acesso ao disco, ou seja, resolução de link simbólico .

Leitura adicional:

• PATH_RESOLUTION(7)
• ABERTO(2)
• LINK(2)
• SYMLINK(2)
• ESTAT(2)