Quantas vezes o disco é acessado?

Question

Isso é sobre o UFS genérico .

Pelo que entendi quando um caminho absoluto é fornecido (por exemplo: /home/userU/file.txt ), o disco é acessado para cada diretório e o arquivo. Por isso, neste caso, o disco é acessado 4 vezes

1 Para / , 1 para home/ , 1 para /userU , 1 para file.txt

Minhas perguntas são

1. Se um link físico /hL for fornecido, apontando para o inode do arquivo acima, em que ordem o disco é acessado?
2. Se um link de software /sL for fornecido, apontando para o arquivo acima, em qual ordem o disco será acessado?

Suponha que nenhum inodes ou qualquer outro dado seja armazenado em cache nos três casos.

    

Answer 1

Antecedentes

Digamos que tenhamos 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 duas perguntas.

Perguntas

1. If a hard link /hL is given, pointing to the inode of the above file, in what order is the disk accessed?

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 adicional ao HDD 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 dois é o nome. Assim, qualquer caminho terá o mesmo número de acessos ao disco rígido.

2. If a soft link /sL is given, pointing to the above file, in what order is the disk accessed?

Com links suaves, no entanto, há um acesso adicional ao HDD. Esse acesso adicional seria contra os metadados do diretório, onde o arquivo sL reside. Isso retornaria detalhes indicando que esse arquivo é, na verdade, 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 isso vai custar uma leitura adicional.

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

Se você usa strace contra o próprio Bash shell, no qual você está executando comandos nesses arquivos / diretórios, pode 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)

Mais detalhes

A página da Wikipédia sobre links simbólicos ilude a tudo isso também:

Although storing the link value inside the inode saves a disk block and a disk read, the operating system still needs to parse the path name in the link, which always requires reading additional inodes and generally requires reading other, and potentially many, directories, processing both the list of files and the inodes of each of them until it finds a match with the link's path components. Only when a link points to a file in the same directory do "fast symlinks" provide significantly better performance than other symlinks.

Referências

• Links simbólicos - Wikipedia

Answer 2

As duas perguntas feitas são, na verdade, a pergunta: "Como o path_resolution funciona?", portanto, basta olhar para todo o processo a partir desse ponto de vista.

De PATH_RESOLUTION (7) lemos:

A filename (or pathname) is resolved as follows.

E depois vemos que o primeiro passo é comum para hardlinks e symlinks (onde o sistema decide qual é o ponto inicial da resolução do caminho: diretório raiz / , diretório chrooted ou diretório atual).

If the pathname starts with the '/' character, the starting lookup directory is the root directory of the calling process. (A process inherits its root directory from its parent. Usually this will be the root directory of the file hierarchy. A process may get a different root directory by use of the chroot(2) system call. A process may get an entirely private mount namespace in case it—or one of its ancestors—was started by an invocation of the clone(2) system call that had the CLONE_NEWNS flag set.) This handles the '/' part of the pathname.

If the pathname does not start with the '/' character, the starting lookup directory of the resolution process is the current working directory of the process. (This is also inherited from the parent. It can be changed by use of the chdir(2) system call.)

Pathnames starting with a '/' character are called absolute pathnames. Pathnames not starting with a '/' are called relative pathnames.

Como não vemos diferença para o ponto de partida entre hard- e links simbólicos. Mas, uma diferença aparece no próximo passo quando o caminho começa:

Set the current lookup directory to the starting lookup directory. Now, for each nonfinal component of the pathname, where a component is a substring delimited by '/' characters, this component is looked up in the current lookup directory.

If the process does not have search permission on the current lookup directory, an EACCES error is returned ("Permission denied").

If the component is not found, an ENOENT error is returned ("No such file or directory"). If the component is found, but is neither a directory nor a symbolic link, an ENOTDIR error is returned ("Not a directory").

If the component is found and is a directory, we set the current lookup directory to that directory, and go to the next component.

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

If the component is found and is a symbolic link (symlink), we first resolve this symbolic link (with the current lookup directory as starting lookup directory). Upon error, that error is returned. If the result is not a directory, an ENOTDIR error is returned. If the resolution of the symlink is successful and returns a directory, we set the current lookup directory to that directory, and go to the next component. Note that the resolution process here can involve recursion if the prefix ('dirname') component of a pathname contains a filename that is a symbolic link that resolves to a directory (where the prefix component of that directory may contain a symbolic link, and so on). In order to protect the kernel against stack overflow, and also to protect against denial of service, there are limits on the maximum recursion depth, and on the maximum number of symbolic links followed. An ELOOP error is returned when the maximum is exceeded ("Too many levels of symbolic links").

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

If a hard link /hL is given, pointing to the inode of the above file, in what order is the disk accessed?

e

If a soft link /sL is given, pointing to the above file, in what order is the disk accessed?

podemos concluir que o acesso aos hardlinks não difere do acesso a arquivos comuns, 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)
• OPEN (2)
• LINK (2)
• SYMLINK (2)
• STAT (2)