Tudo o que você sempre quis saber sobre inodes no Linux
Fatmawati Achmad Zaenuri / Shutterstock
O sistema de arquivos Linux depende de inodes. Essas partes vitais do funcionamento interno do sistema de arquivos geralmente são mal compreendidas. Vamos analisar exatamente o que 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, precisa registrar onde todos os arquivos estão localizados no sistema de arquivos, como eles são chamados, em quais contas eles pertencem, em quais permissões eles têm e muito mais. Essa informação é chamada de metadados, porque são dados que descrevem outros dados.
No sistema de arquivos ext4 do Linux, as estruturas de inode e de diretório trabalham juntas para fornecer uma estrutura subjacente que armazena todos os metadados para cada arquivo e diretório. Eles disponibilizam os metadados para quem precisar, seja o kernel, aplicativos de usuário ou utilitários Linux, como ls, stat e df.
Inodes e tamanho do sistema de arquivos
Embora seja verdade que existe um par de estruturas, um sistema de arquivos requer muito mais que isso. Existem milhares e milhares de cada estrutura. Todo arquivo e diretório requer um inode e, como todo arquivo está em um diretório, todo arquivo também requer uma estrutura de diretórios. 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, único 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 criar um identificador exclusivo, independentemente de quantos sistemas de arquivos estão montados no 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, para que seja fácil ter vários sistemas de arquivos sem perceber. Se você possui vários discos rígidos ou partições em uma única unidade, possui mais de um sistema de arquivos. Eles podem ser do mesmo tipo "todos os ext4, por exemplo", mas ainda serão sistemas de arquivos distintos.
Todos os inodes são mantidos em uma tabela. Usando um número de inode, o sistema de arquivos calcula facilmente o deslocamento na tabela de inodes na qual esse inode está localizado. Você pode ver por que o “ i ” inode significa index.
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 do inode é um valor inteiro com um tamanho máximo de 2 ^ 32, calculado em 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 na 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 arquivos e diretórios são criados dentro do sistema de arquivos.
Existe um comando que você pode usar para ver quantos inodes estão em um sistema de arquivos no seu computador. A opção -i (inodes) do comando df instrui-o a exibir sua saída em número de inodes.
Vamos analisar o sistema de arquivos na primeira partição do primeiro disco rígido, então digitamos o seguinte:
df -i / dev / sda1
A saída nos fornece:
- Sistema de arquivos: o sistema de arquivos que está sendo relatado.
- Inodes: o número total de inodes nesse sistema de arquivos.
- IUsed: o número de inodes em uso .
- IFree: O número de inodes restantes disponíveis para uso.
- IUse%: a porcentagem de inodes usados.
- Montado em: o ponto de montagem deste sistema de arquivos.
Utilizamos 10% 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 eles representam. Se você possui milhões de arquivos minúsculos, pode ficar sem inodes antes de ficar sem espaço no disco rígido. No entanto, esse é um problema muito difícil de se encontrar.
No passado, alguns servidores de email que armazenavam mensagens de email como arquivos discretos (que rapidamente levavam a grandes coleções de arquivos pequenos) tinham esse problema. Quando esses aplicativos alteraram seus back-ends para bancos de dados, isso resolveu o problema. O sistema doméstico médio não fica sem inodes, o que também é 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 comando blockdev com a opção --getbsz (obter tamanho do bloco):
sudo blockdev --getbsz / dev / sda
O tamanho do bloco é 4096 bytes.
Vamos usar a opção -B (tamanho do bloco) 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 arquivos: o sistema de arquivos no qual estamos relatando.
- Blocos de 4K: o número total de blocos de 4 KB neste sistema de arquivos.
- Usado: quantos blocos de 4K estão em uso.
- Disponível: o número de blocos restantes de 4 KB disponíveis para uso.
- Use%: a porcentagem de blocos de 4 KB que foram usados.
- Montado em: o ponto de montagem deste sistema de arquivos.
No nosso exemplo, o armazenamento de arquivos (e o armazenamento dos inodes e das estruturas de diretórios) utilizaram 28% do espaço neste sistema de arquivos, ao custo de 10% dos inodes, portanto, estamos em boa forma .
metadados de inode
Para ver o número de inode de um arquivo, podemos usar ls com a opção -i (inode):
ls -i geek. txt
O número do inode para esse arquivo é 1441801, portanto, esse inode mantém os metadados desse arquivo e, tradicionalmente, os ponteiros para os blocos de disco em que 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 outros indicadores para outros blocos de 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 ser de tamanho fixo e capaz de reter um número finito de ponteiros para blocos de disco.
Esse método foi substituído por um novo esquema que faz uso das extensões. ” Eles registram o bloco inicial e final de cada conjunto de blocos contíguos usados para armazenar o arquivo. Se o arquivo não estiver fragmentado, você precisará armazenar apenas o primeiro bloco e o tamanho do arquivo. Se o arquivo estiver fragmentado, você precisará armazenar o primeiro e o último bloco de cada parte do arquivo. Este método é (obviamente) mais eficiente.
Se você quiser ver se o seu sistema de arquivos usa ponteiros ou extensões de bloco de disco, é possível procurar dentro de um inode. Para fazer isso, usaremos o comando debugfs com a opção -R (request) e transmitiremos o inode do arquivo de interesse. Isso solicita que os debugfs usem suas estatísticas internas; comando para exibir o conteúdo do inode. Como os números de inode são únicos apenas dentro de um sistema de arquivos, também devemos informar ao debugfs o sistema de arquivos no qual o inode reside.
Aqui está a aparência desse comando de exemplo:
sudo debugfs -R "stat < 1441801 >" / dev / sda1
Como mostrado abaixo, o comando debugfs extrai as informações do inode e as apresenta em menos:
Mostramos as seguintes informações:
- Inode: o número do inode que estamos vendo.
- Tipo: este é um arquivo comum, não um diretório ou link simbólico.
- Modo: as permissões de arquivo em octal.
- Sinalizadores: indicadores que representam diferentes recursos ou funcionalidades. O 0x80000 é o “ extensões ” sinalizador (mais sobre isso abaixo).
- Geração: um NFS (Network File System) usa isso quando alguém acessa sistemas de arquivos remotos através de uma conexão de rede como se estivessem montados na máquina local. Os números de inode e de geração são usados como uma forma de tratamento de arquivo.
- Versão: a versão do inode.
- Usuário: o proprietário do arquivo.
- Grupo : O proprietário do grupo do arquivo.
- Projeto: sempre deve ser zero.
- Tamanho: o tamanho do arquivo.
- Arquivo ACL: acesso ao arquivo lista de controle. Eles foram projetados para permitir que você conceda acesso controlado a pessoas que não estão no grupo de proprietários.
- Links: o número de links físicos para o arquivo.
- Número de blocos: A quantidade de espaço no disco rígido alocada para esse arquivo, fornecida em blocos de 512 bytes. Nosso arquivo foi alocado oito deles, que são 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: o horário em que o arquivo foi criado.
- Atime: o horário em que este arquivo foi acessado pela última vez. < litime Mtime: a hora em que este arquivo foi modificado pela última vez.
- Crtime: a hora em que o arquivo foi criado.
- Tamanho dos campos extras de inode: o sistema de arquivos ext4 introduzido 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 de novos kernels ou para armazenar atributos estendidos.
- Soma de verificação do inode: 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 referentes ao uso de arquivos em disco 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 todos os blocos de disco ocupados por cada parte de um arquivo. Temos uma extensão, porque nosso arquivo pequeno fica em um bloco de disco nesse 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 obtivemos o nome do arquivo. É aqui que a estrutura de diretórios entra em cena. 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órios contém uma quantidade limitada de informações sobre um arquivo. Ele contém apenas o número do inode, o nome e o tamanho do nome do arquivo.
O inode e a estrutura de diretórios contêm tudo o que você (ou um aplicativo) precisa saber sobre um arquivo ou diretório. A estrutura do diretório está em um bloco de disco do diretório, portanto sabemos o diretório em que o arquivo está. A estrutura do diretório 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 e hora, permissões e onde encontrar os dados do arquivo no sistema de arquivos.
inodes de diretório
Você pode ver o número de inode de um diretório tão facilmente quanto você pode ver os arquivos.
No exemplo a seguir, usaremos ls com as opções -l (formato longo), -i (inode) e -d (diretório) e examinaremos o diretório de trabalho:
ls -lid trabalho /
Como usamos a opção -d (diretório), ls reporta no próprio diretório, não no seu conteúdo. O inode para este diretório é 1443016.
Para repetir isso no diretório inicial, digite o seguinte:
ls -lid ~
O inode para o diretório inicial é 1447510 e o diretório de trabalho está no diretório inicial. Agora, vamos ver o conteúdo do diretório de trabalho. Em vez da opção -d (diretório), usaremos a opção -a (all). Isso nos mostrará as entradas do diretório que geralmente estão ocultas.
Digitamos o seguinte:
ls -lia trabalho /
Como usamos a opção -a (all), as entradas simples (.) e de 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 para o número de inode da entrada de ponto único, é o mesmo número de inode que obtivemos quando descobrimos o número de inode para o diretório de trabalho. Além disso, o número do inode para a entrada de ponto duplo é o mesmo que o número do inode para o diretório pessoal.
É por isso que você pode usar o comando cd .. para subir de nível na árvore de diretórios. Da mesma forma, quando você precede um nome de aplicativo ou script com ./, informa ao shell de onde iniciar o aplicativo ou script.
Inodes e links
Como abordamos, 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órios e o inode. O arquivo são os dados armazenados no disco rígido, a estrutura de diretórios 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 são realmente 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, como mostrado abaixo.
Podemos usar o comando ln e a opção -s (simbólica) para criar um link suave para o arquivo de script, da seguinte forma:
ls -s meu_script geek. sh
Criamos um link para my_script. sh chamado geek. sh. Podemos digitar o seguinte e usar ls para examinar 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 link, e o - > aponta para my_script. sh. Tudo isso indica que o 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 virtual, geek. sh, não tem as mesmas permissões de usuário que o arquivo de script original. De fato, as permissões do geek. sh são muito mais liberais - todos os usuários têm permissões completas.
A estrutura de diretórios do geek. sh contém o nome do link e seu inode. Quando você tenta usar o link, seu inode é referenciado, assim como um arquivo regular. 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 é redirecionado para o arquivo original.
Excluiremos o arquivo original e veremos o que acontece quando digitarmos o seguinte para exibir o conteúdo de geek. sh:
rm meu_script. sh
gato geek. sh
O link simbólico está quebrado e o redirecionamento falha.
Agora, digitamos o seguinte para criar um link físico para o arquivo do aplicativo:
No aplicativo especial geek-app
Para examinar os inodes desses dois arquivos, digitamos o seguinte:
ls -li
Ambos parecem arquivos comuns. Nada no geek-app indica que ele é um link da maneira que a listagem do geek. sh fez. Além disso, o geek-app tem as mesmas permissões de usuário que o arquivo original. No entanto, o que pode surpreender é que os dois aplicativos tenham o mesmo número de inode: 1441797.
A entrada de diretório para o geek-app contém o nome 'geek-app' ” e um número de inode, mas é o mesmo que o número de inode do arquivo original. Portanto, temos duas entradas do sistema de arquivos com nomes diferentes que apontam para o mesmo inode. De fato, qualquer número de itens pode apontar para o mesmo inode.
Digitaremos o seguinte e usaremos o programa stat para examinar o arquivo de destino:
stat-app especial
Vemos que dois links físicos apontam para esse arquivo. Isso é armazenado no inode.
No exemplo a seguir, excluímos o arquivo original e tentamos usar o link com uma senha segura e secreta:
rm aplicativo especial
./ geek-app correcthorsebatterystaple
Se o número de links físicos para o inode for maior que um, no entanto, a contagem de links físicos será reduzida em um, e o número de inodos da estrutura de diretório do arquivo excluído será definido como zero. O conteúdo do arquivo no disco rígido e no inode ainda estão disponíveis para os links físicos existentes.
Digitaremos o seguinte e usaremos stat mais uma vez, desta vez no geek-app:
stat geek-app
Esses detalhes são obtidos do mesmo inode (1441797) que o comando stat anterior. A contagem de links foi reduzida em um.
Como reduzimos para um link físico para este inode, se excluirmos o geek-app, ele realmente excluiria o arquivo. O sistema de arquivos liberará o inode e marcará a estrutura de 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
Sobrecarga de inode
é um sistema elegante, mas há custos indiretos. Para ler um arquivo, o sistema de arquivos deve fazer o seguinte:
- Encontre a estrutura de diretórios correta
- 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 dos blocos de disco relevantes
- Leia os dados do arquivo
Um pouco mais de salto é necessário se os dados não forem contíguos.
Imagine o trabalho que deve ser feito para o ls executar uma lista de arquivos de formato longo com muitos arquivos. Há muitas idas e vindas apenas para que as pessoas obtenham as informações necessárias 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 cache de arquivos preventivo. Isso ajuda muito, mas às vezes "como em qualquer sistema de arquivos", as despesas gerais podem se tornar aparentes.
Agora você saberá o porquê.
Via: How to Geek
Veja Também:
Nenhum comentário