agwebrunner.com

O sistema de arquivos Linux depende de inodes. Essas partes vitais do funcionamento interno do sistema de arquivos costumam ser mal compreendidas. Vamos ver exatamente o que eles são e o que fazem.

Os elementos de um sistema de arquivos

Por definição, um sistema de arquivos precisa armazenar arquivos e eles também contêm diretórios. Os arquivos são armazenados nos diretórios e esses diretórios podem ter subdiretórios. Algo, em algum lugar, deve registrar onde todos os arquivos estão localizados no sistema de arquivos, como são chamados, a quais contas pertencem, quais permissões possuem e muito mais. Essas informações são chamadas de metadados porque são dados que descrevem outros dados.

No sistema de arquivos ext4 do Linux, as estruturas de inode e diretório trabalham juntas para fornecer uma estrutura de apoio que armazena todos os metadados para cada arquivo e diretório. Eles disponibilizam os metadados para qualquer pessoa que os necessite, seja o kernel, aplicativos de usuário ou utilitários do Linux, como ls, Estado, e df.

Inodes e tamanho do sistema de arquivos

Embora seja verdade que há um par de estruturas, um sistema de arquivos requer muito mais do que isso. Existem milhares e milhares de cada estrutura. Cada arquivo e diretório requer um inode e, como cada arquivo está em um diretório, cada arquivo também requer uma estrutura de diretório. As estruturas de diretório também são chamadas de entradas de diretório ou “dentries”.

Cada inode possui um número de inode, que é exclusivo em um sistema de arquivos. O mesmo número de inode pode aparecer em mais de um sistema de arquivos. No entanto, o ID do sistema de arquivos e o número do inode se combinam para formar um identificador exclusivo, independentemente de quantos sistemas de arquivos estão montados em seu sistema Linux.

Lembre-se, no Linux, você não monta um disco rígido ou partição. Você monta o sistema de arquivos que está na partição, então é fácil ter vários sistemas de arquivos sem perceber. Se você tiver vários discos rígidos ou partições em uma única unidade, terá mais de um sistema de arquivos. Eles podem ser do mesmo tipo - todos ext4, por exemplo - mas ainda serão sistemas de arquivos distintos.

Todos os inodes são mantidos em uma mesa. Usando um número de inode, o sistema de arquivos calcula facilmente o deslocamento na tabela de inode na qual esse inode está localizado. Você pode ver porque o “i” em inode significa índice.

A variável que contém o número do inode é declarada no código-fonte como um inteiro longo sem sinal de 32 bits. Isso significa que o número de inode é um valor inteiro com um tamanho máximo de 2 ^ 32, que calcula para 4.294.967.295 - bem mais de 4 bilhões de inodes.

Esse é o máximo teórico. Na prática, o número de inodes em um sistema de arquivos ext4 é determinado quando o sistema de arquivos é criado em uma proporção padrão de um inode por 16 KB de capacidade do sistema de arquivos. As estruturas de diretório são criadas dinamicamente quando o sistema de arquivos está em uso, à medida que os arquivos e diretórios são criados dentro do sistema de arquivos.

Há um comando que você pode usar para ver quantos inodes estão em um sistema de arquivos em seu computador. O -eu (inodes) opção do df o comando o instrui a exibir sua saída em números de inodes.

Vamos dar uma olhada no sistema de arquivos da primeira partição do primeiro disco rígido, então digitamos o seguinte:

df -i / dev / sda1

A saída nos dá:

• Sistema de arquivo: O sistema de arquivos que está sendo relatado.
• Inodes: O número total de inodes neste sistema de arquivos.
• Eu usei: O número de inodes em uso.
• Eu livre: O número de inodes restantes disponíveis para uso.
• Eu uso%: A porcentagem de inodes usados.
• Montado em: O ponto de montagem para este sistema de arquivos.

Usamos 10 por cento dos inodes neste sistema de arquivos. Os arquivos são armazenados no disco rígido em blocos de disco. Cada inode aponta para os blocos de disco que armazenam o conteúdo do arquivo que representam. Se você tem milhões de arquivos minúsculos, pode ficar sem inodes antes de ficar sem espaço no disco rígido. No entanto, é um problema muito difícil de enfrentar.

No passado, alguns servidores de e-mail que armazenavam mensagens de e-mail como arquivos distintos (o que rapidamente gerava grandes coleções de pequenos arquivos) tinham esse problema. Quando esses aplicativos mudaram seus back-ends para bancos de dados, o problema foi resolvido. O sistema doméstico comum não fica sem inodes, o que é bom porque, com o sistema de arquivos ext4, você não pode adicionar mais inodes sem reinstalar o sistema de arquivos.

Para ver o tamanho dos blocos de disco em seu sistema de arquivos, você pode usar o blockdev comando com o --getbsz (obter tamanho do bloco) opção:

sudo blockdev --getbsz / dev / sda

O tamanho do bloco é de 4096 bytes.

Vamos usar o -B (tamanho do bloco) opção para especificar um tamanho de bloco de 4096 bytes e verificar o uso regular do disco:

df -B 4096 / dev / sda1

Esta saída nos mostra:

• Sistema de arquivo: O sistema de arquivos sobre o qual estamos relatando.
• Blocos de 4 K: O número total de blocos de 4 KB neste sistema de arquivos.
• Usava: Quantos blocos de 4 K estão em uso.
• Disponível: O número de blocos restantes de 4 KB disponíveis para uso.
• Usar%: A porcentagem de blocos de 4 KB que foram usados.
• Montado em: O ponto de montagem para este sistema de arquivos.

Em nosso exemplo, o armazenamento de arquivos (e armazenamento dos inodes e estruturas de diretório) usou 28 por cento do espaço neste sistema de arquivos, ao custo de 10 por cento dos inodes, então estamos em boa forma.

Metadados Inode

Para ver o número de inode de um arquivo, podemos usar ls com o -eu (inode) opção:

ls -i geek.txt

O número de inode para este arquivo é 1441801, portanto, este inode contém os metadados para este arquivo e, tradicionalmente, os ponteiros para os blocos de disco onde o arquivo reside no disco rígido. Se o arquivo estiver fragmentado, muito grande ou ambos, alguns dos blocos para os quais o inode aponta podem conter mais ponteiros para outros blocos do disco. E alguns desses outros blocos de disco também podem conter ponteiros para outro conjunto de blocos de disco. Isso supera o problema do inode ter um tamanho fixo e ser capaz de conter um número finito de ponteiros para blocos de disco.

Esse método foi substituído por um novo esquema que faz uso de "extensões". Eles registram o bloco inicial e final de cada conjunto de blocos contíguos usados ​​para armazenar o arquivo. Se o arquivo for desfragmentado, você só precisa armazenar o primeiro bloco e o comprimento do arquivo. Se o arquivo estiver fragmentado, você deve armazenar o primeiro e o último bloco de cada parte do arquivo. Este método é (obviamente) mais eficiente.

Se você quiser ver se seu sistema de arquivos usa ponteiros ou extensões de bloco de disco, você pode olhar dentro de um inode. Para fazer isso, vamos usar o debugfs comando com o -R (solicitação) e passe a ela o inode do arquivo de interesse. Isso pededebugfs para usar seu comando interno “stat” para exibir o conteúdo do inode. Como os números de inode são únicos em um sistema de arquivos, também devemos informar debugfs o sistema de arquivos no qual o inode reside.

Esta é a aparência deste comando de exemplo:

sudo debugfs -R "stat" / dev / sda1

Conforme mostrado abaixo, o debugfs comando extrai as informações do inode e as apresenta para nós em menos:

Vemos as seguintes informações:

• Inode: O número do inode que estamos olhando.
• Modelo: Este é um arquivo normal, não um diretório ou link simbólico.
• Modo: As permissões do arquivo em octal.
• Bandeiras: Indicadores que representam diferentes recursos ou funcionalidades. O 0x80000 é o sinalizador “extents” (mais sobre isso abaixo).
• Geração: Um Network File System (NFS) usa isso quando alguém acessa sistemas de arquivos remotos em uma conexão de rede como se eles estivessem montados na máquina local. Os números de inode e geração são usados ​​como uma forma de identificador de arquivo.
• Versão: A versão do inode.
• Do utilizador: O proprietário do arquivo.
• Grupo: O proprietário do grupo do arquivo.
• Projeto: Deve ser sempre zero.
• Tamanho: O tamanho do arquivo.
• Arquivo ACL: A lista de controle de acesso ao arquivo. Eles foram projetados para permitir que você conceda acesso controlado a pessoas que não fazem parte do grupo proprietário.
• Links: O número de links físicos para o arquivo.
• Blockcount: A quantidade de espaço em disco rígido alocada para este arquivo, fornecida em blocos de 512 bytes. Nosso arquivo tem oito alocados, o que equivale a 4.096 bytes. Portanto, nosso arquivo de 98 bytes fica em um único bloco de disco de 4.096 bytes.
• Fragmento: Este arquivo não está fragmentado. (Este é um sinalizador obsoleto.)
• Ctime: A hora em que o arquivo foi criado.
• Um tempo: A hora em que este arquivo foi acessado pela última vez.
• Mtime: A hora em que este arquivo foi modificado pela última vez.
• Crtime: A hora em que o arquivo foi criado.
• Tamanho dos campos inode extras: O sistema de arquivos ext4 introduziu a capacidade de alocar um inode maior no disco no momento da formatação. Este valor é o número de bytes extras que o inode está usando. Esse espaço extra também pode ser usado para acomodar requisitos futuros para novos kernels ou para armazenar atributos estendidos.
• Inode checksum: Uma soma de verificação para este inode, que permite detectar se o inode está corrompido.
• Extensões: Se extensões estiverem sendo usadas (no ext4, elas são, por padrão), os metadados relacionados ao uso do bloco de disco de arquivos têm dois números que indicam os blocos inicial e final de cada parte de um arquivo fragmentado. Isso é mais eficiente do que armazenar cada bloco de disco ocupado por cada parte de um arquivo. Temos uma extensão porque nosso pequeno arquivo fica em um bloco de disco neste deslocamento de bloco.

Onde está o nome do arquivo?

Agora temos muitas informações sobre o arquivo, mas, como você deve ter notado, não conseguimos o nome do arquivo. É aqui que a estrutura do diretório entra em jogo. No Linux, assim como um arquivo, um diretório possui um inode. Em vez de apontar para blocos de disco que contêm dados de arquivo, um inode de diretório aponta para blocos de disco que contêm estruturas de diretório.

Comparada a um inode, uma estrutura de diretório contém uma quantidade limitada de informações sobre um arquivo. Ele contém apenas o número do inode do arquivo, o nome e o comprimento do nome.

O inode e a estrutura de diretório contêm tudo que você (ou um aplicativo) precisa saber sobre um arquivo ou diretório. A estrutura de diretório está em um bloco de disco de diretório, portanto sabemos em que diretório o arquivo está. A estrutura de diretório nos fornece o nome do arquivo e o número do inode. O inode nos diz tudo o mais sobre o arquivo, incluindo carimbos de data / hora, permissões e onde encontrar os dados do arquivo no sistema de arquivos.

Diretório Inodes

Você pode ver o número de inode de um diretório com a mesma facilidade com que vê os arquivos.

No exemplo a seguir, usaremos ls com o -eu (formato longo), -eu (inode), e -d (diretório) opções, e olhe para as trabalhos diretório:

ls -lid work /

Porque usamos o -d opção (diretório),ls relatórios sobre o próprio diretório, não seu conteúdo. O inode para este diretório é 1443016.

Para repetir isso para o casa diretório, digitamos o seguinte:

ls -lid ~

O inode para o casa diretório é 1447510, e o trabalhos diretório está no diretório inicial. Agora, vamos dar uma olhada no conteúdo do trabalhos diretório. Ao invés de-d opção (diretório), usaremos a -uma (todos) opção. Isso nos mostrará as entradas do diretório que geralmente estão ocultas.

Nós digitamos o seguinte:

ls -lia trabalho /

Porque usamos o -uma opção (todos), as entradas de ponto único (.) e ponto duplo (..) são exibidas. Essas entradas representam o próprio diretório (ponto único) e seu diretório pai (ponto duplo).

Se você olhar o número do inode para a entrada de ponto único, você verá que é 1443016 - o mesmo número do inode que obtivemos quando descobrimos o número do inode para o trabalhos diretório. Além disso, o número do inode para a entrada de dois pontos é o mesmo que o número do inode para o casa diretório.

É por isso que você pode usar o CD .. comando para subir um nível na árvore de diretórios. Da mesma forma, quando você precede um nome de aplicativo ou script com./, você permite que o shell saiba de onde iniciar o aplicativo ou script.

Inodes e Links

Como vimos, três componentes são necessários para ter um arquivo bem formado e acessível no sistema de arquivos: o arquivo, a estrutura de diretório e o inode. O arquivo são os dados armazenados no disco rígido, a estrutura do diretório contém o nome do arquivo e seu número de inode e o inode contém todos os metadados do arquivo.

Links simbólicos são entradas do sistema de arquivos que se parecem com arquivos, mas na verdade são atalhos que apontam para um arquivo ou diretório existente. Vamos ver como eles gerenciam isso e como os três elementos são usados ​​para conseguir isso.

Digamos que temos um diretório com dois arquivos: um é um script e o outro é um aplicativo, conforme mostrado abaixo.

Podemos usar o comando ln e o -s opção (simbólica) para criar um link simbólico para o arquivo de script, assim:

ls -s my_script geek.sh

Criamos um link para my_script.sh chamado geek.sh. Podemos digitar o seguinte e usarls para ver os dois arquivos de script:

ls -li * .sh

A entrada para geek.sh aparece em azul. O primeiro caractere dos sinalizadores de permissões é um “l” para o link e o-> aponta para my_script.sh . Tudo isso indica que geek.sh é um link.

Como você provavelmente espera, os dois arquivos de script têm números de inode diferentes. O que pode ser mais surpreendente, porém, é o link simbólico, geek.sh, não tem as mesmas permissões de usuário do arquivo de script original. Na verdade, as permissões parageek.sh são muito mais liberais - todos os usuários têm permissões completas.

A estrutura do diretório para geek.sh contém o nome do link e seu inode. Quando você tenta usar o link, seu inode é referenciado, assim como um arquivo normal. O inode do link apontará para um bloco de disco, mas em vez de conter dados de conteúdo do arquivo, o bloco de disco contém o nome do arquivo original. O sistema de arquivos redireciona para o arquivo original.

Excluiremos o arquivo original e veremos o que acontece quando digitarmos o seguinte para visualizar o conteúdo degeek.sh:

rm my_script.sh

gato geek.sh

O link simbólico é quebrado e o redirecionamento falha.

Agora digitamos o seguinte para criar um link físico para o arquivo do aplicativo:

Em um aplicativo especial geek

Para ver os inodes desses dois arquivos, digitamos o seguinte:

ls -li

Ambos parecem arquivos normais. Nada sobre app geek indica que é um link na forma como o ls listagem para geek.sh fez. Mais,app geek tem as mesmas permissões de usuário do arquivo original. No entanto, o que pode ser surpreendente é que ambos os aplicativos têm o mesmo número de inode: 1441797.

A entrada do diretório para app geek contém o nome “geek-app” e um número de inode, mas é igual ao número de inode do arquivo original. Portanto, temos duas entradas do sistema de arquivos com nomes diferentes que apontam para o mesmo inode. Na verdade, qualquer número de itens pode apontar para o mesmo inode.

Vamos digitar o seguinte e usar o Estado programa para olhar para o arquivo de destino:

stat especial-app

Vemos que dois links físicos apontam para este arquivo. Isso é armazenado no inode.

No exemplo a seguir, excluímos o arquivo original e tentamos usar o link com uma senha secreta e segura:

rm app-especial

./geek-app correcthorsebatterystaple

Surpreendentemente, o aplicativo funciona conforme o esperado, mas como? Funciona porque, ao excluir um arquivo, o inode está livre para ser reutilizado. A estrutura do diretório é marcada como tendo um número de inode zero e os blocos do disco ficam então disponíveis para outro arquivo a ser armazenado naquele espaço.

Se o número de links físicos para o inode for maior que um, no entanto, a contagem de links físicos é reduzida em um e o número de inode da estrutura de diretório do arquivo excluído é definido como zero. O conteúdo do arquivo no disco rígido e inode ainda está disponível para os links físicos existentes.

Vamos digitar o seguinte e usar estatísticas mais uma vez - desta vez em app geek:

stat geek-app

Esses detalhes são extraídos do mesmo inode (1441797) que o anterior Estado comando. A contagem de links foi reduzida em um.

Porque estamos reduzidos a um link físico para este inode, se excluirmosapp geek, isso realmente excluiria o arquivo. O sistema de arquivos liberará o inode e marcará a estrutura do diretório com um inode zero. Um novo arquivo pode substituir o armazenamento de dados no disco rígido.

RELACIONADO:Como usar o comando stat no Linux

Inode Overheads

é um sistema limpo, mas há sobrecargas. Para ler um arquivo, o sistema de arquivos deve fazer o seguinte:

• Encontre a estrutura de diretório certa
• Leia o número do inode
• Encontre o inode certo
• Leia as informações do inode
• Siga os links de inode ou as extensões para os blocos de disco relevantes
• Leia os dados do arquivo

Um pouco mais de pulos é necessário se os dados não forem contíguos.

Imagine o trabalho que deve ser feito parals para realizar uma listagem de arquivos de formato longo de muitos arquivos. Há muitas idas e vindas apenas para ls para obter as informações de que precisa para gerar sua saída.

Obviamente, acelerar o acesso ao sistema de arquivos é o motivo pelo qual o Linux tenta fazer o máximo possível de armazenamento em cache preventivo de arquivos. Isso ajuda muito, mas às vezes - como em qualquer sistema de arquivos - as sobrecargas podem se tornar aparentes.

Agora você saberá por quê.