Links simbólicos rápidos e lentos

Question

Em link

Early implementations of symbolic links stored the symbolic link information as data in regular files. The file contained the textual reference to the link’s target, and an indicator[clarification needed] denoting it as a symbolic link.

This method was slow and an inefficient use of disk-space on small systems. An improvement, called fast symlinks, allowed storage of the target path within the data structures used for storing file information on disk (inodes). This space normally stores a list of disk block addresses allocated to a file. Thus, symlinks with short target paths are accessed quickly. Systems with fast symlinks often fall back to using the original method if the target path exceeds the available inode space. The original style is retroactively termed a slow symlink. It is also used for disk compatibility with other or older versions of operating systems.

1. Faz "armazenamento permitido do caminho de destino nas estruturas de dados usado para armazenar informações de arquivo no disco (inodes) "significa que um symlink armazena o caminho do arquivo vinculado dentro do inode do link simbólico rápido

   Um link simbólico rápido, como um arquivo em si, na verdade só tem um inode e não tem conteúdo de arquivo?

   Um link simbólico lento, como um arquivo em si, tem um inode e algum arquivo conteúdo que é o caminho de destino?

2. O que significa "se o caminho de destino exceder o espaço de inode disponível" significa?

   É correto que, se um link simbólico para um arquivo for um link simbólico rápido, se e somente se o link simbólico e o arquivo estiverem no mesmo sistema de arquivos?

3. Existe algum comando que possa verificar se um link simbólico é rápido ou lento 1?

4. Quando um link simbólico tem conteúdo de arquivo, qual é o comando para mostrar o conteúdo do symlink? (Então, se um link simbólico rápido não tiver arquivo conteúdo e um lento, podemos verificar isso.)

Answer 1

Does "allowed storage of the target path within the data structures used for storing file information on disk (inodes)" mean that a fast symlink stores the path of the linked file inside the inode of the fast symlink

Sim

Does a fast symlink, as a file itself, actually only have an inode and has no file content?

Depende do que você quer dizer com "conteúdo do arquivo". Nenhum link simbólico tem conteúdo de arquivo no sentido de que você não pode open() deles e read() deles. Mas, no significado implícito no texto citado, "O arquivo continha a referência textual ao destino do link". Então, sim, essa referência textual pode ser considerada o "conteúdo" do arquivo.

Esse conteúdo é o mesmo, independentemente de o link simbólico ser um link simbólico rápido ou um link simbólico lento. Como e onde o sistema de arquivos escolhe armazenar essas informações em suas estruturas de dados em disco é um detalhe de implementação e não afeta isso.

Does a slow symlink, as a file itself, have an inode and some file content which is the target path?

Do mesmo ponto de vista, sim!

What does "if the target path exceeds the available inode space" mean?

Depende do sistema de arquivos e do tipo de estruturas de dados que ele usou para armazenar inodes e quanto espaço livre há nessas estruturas de dados e se elas são de tamanho variável ou fixo. O comprimento máximo do caminho de destino de um link simbólico antes que ele tenha que voltar a ser armazenado como um link simbólico lento é um detalhe de implementação do sistema de arquivos.

A propósito, nada impede que um determinado sistema de arquivos use o mesmo truque para armazenar o conteúdo de um arquivo regular curto para economizar espaço e acesso ao disco.

Is there any command that can check if a symlink is a fast or slow one?

Na melhor das hipóteses, ferramentas de depuração ou despejo do sistema de arquivos. E será completamente dependente do tipo de sistema de arquivos que você está interessado (xfs, ext *, btrfs, etc ...)

When a symlink has file content, what is the command to show the content of the symlink? (So that if a fast symlink doesn't have file content and a slow one has, we can verfiy that.)

Você pode obter o caminho de destino (conteúdo) de um symlink com readlink , mas ls -l também funcionará.

    

Answer 2

Na página wiki inode vinculada:

A file system relies on data structures about the files, beside the file content. The former is called metadata—data that describes data. Each file is associated with an inode, which is identified by an integer number, often referred to as an i-number or inode number.

Inodes store information about files and directories (folders), such as file ownership, access mode (read, write, execute permissions), and file type. On many types of file system implementations, the maximum number of inodes is fixed at file system creation, limiting the maximum number of files the file system can hold. A typical allocation heuristic for inodes in a file system is one percent of total size.

The inode number indexes a table of inodes in a known location on the device; from the inode number, the file system driver portion of the kernel can access the contents of the inode, including the location of the file allowing access to the file. A file's inode number can be found using the ls -i command. The ls -i command prints the i-node number in the first column of the report.

Como mencionado acima, ls -i pode fornecer o número do inode - o que é provável onde o link está. ls -l fornecerá um caminho para o destino do link. Este último requererá stat() syscall, mas, como a listagem de diretórios de um arquivo - seu dentry - conterá seu número de inode e nome de arquivo, a forma ls -i provavelmente não. Pelo menos, dependendo do sistema de arquivos, provavelmente não será necessário um stat() para qualquer objeto de arquivo diferente do diretório que o contém.

Você pode modificar a maneira como ls relata links com as seguintes opções, conforme especificado por POSIX :

-F - Do not follow symbolic links named as operands unless the -H or -L options are specified. Write a slash ( '/' ) immediately after each pathname that is a directory, an asterisk ( '*' ) after each that is executable, a vertical bar ( '|' ) after each that is a FIFO, and an at sign ( '@' ) after each that is a symbolic link. For other file types, other symbols may be written.

-H - If a symbolic link referencing a file of type directory is specified on the command line, ls shall evaluate the file information and file type to be those of the file referenced by the link, and not the link itself; however, ls shall write the name of the link itself and not the file referenced by the link.

-L - Evaluate the file information and file type for all symbolic links (whether named on the command line or encountered in a file hierarchy) to be those of the file referenced by the link, and not the link itself; however, ls shall write the name of the link itself and not the file referenced by the link. When -L is used with -l, write the contents of symbolic links in the long format (see the STDOUT section).

E como o link pode ser rápido ? Na mesma página wiki vinculada :

Inlining

It can make sense to store very small files in the inode itself to save both space (no data block needed) and look-up time (no further disk access needed). This file system feature is called inlining. The strict separation of inode and file data thus can no longer be assumed when using modern file systems.

If the data of a file fits in the space allocated for pointers to the data, this space can conveniently be used. E.g. ext2 stores the data of symlinks (typically file names) in this way, if the data is no more than 60 bytes ("fast symbolic links").

Ext4 has a file system option called inline_data that, when enabled during file system creation, allows ext4 to perform inlining. As an inode's size is limited, this only works for very small files.

É o método acima que eu acredito que a outra excelente resposta aqui se refere a o mesmo truque ...