O sistema de arquivos do Linux depende de inodes. Essas partes vitais do funcionamento interno do sistema de arquivos costumam ser mal compreendidas. Vejamos exatamente o que são e o que fazem.
Índice
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 dentro do 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 de diretório trabalham juntas para fornecer uma estrutura de apoio que armazena todos os metadados para cada arquivo e diretório. Eles fazem os metadados disponíveis para quem exige que, se isso é o kernel, aplicativos do usuário, ou utilitários de Linux, tais como ls, stat, 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, portanto, é 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 arquivos e diretórios são criados dentro do sistema de arquivos.
Existe um comando que você pode usar para ver quantos inodes existem em um sistema de arquivos em seu computador. A -iopção (inodes) do dfcomando 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 arquivos : O sistema de arquivos que está sendo relatado.
- Inodes : O número total de inodes neste 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 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 blockdevcomando 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 sobre o qual estamos relatando.
- Blocos de 4 K : O número total de blocos de 4 KB neste sistema de arquivos.
- Usado : quantos blocos de 4 K estão em uso.
- Disponível : o número de blocos restantes de 4 KB disponíveis para uso.
- % De uso : 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, portanto, estamos em boa forma.
Metadados Inode
Para ver o número de inode de um arquivo, podemos usar lscom a -iopção (inode):
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 ser de tamanho fixo e 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 o seu sistema de arquivos usa ponteiros ou extensões de bloco de disco, você pode olhar dentro de um inode. Para isso, usaremos o debugfscomando com a -Ropção (pedido) e passaremos a ele o inode do arquivo de interesse . Isso pede debugfs para usar seu comando interno “stat” para exibir o conteúdo do inode. Como os números de inode são exclusivos apenas 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 <1441801>" / dev / sda1
Conforme mostrado abaixo, o debugfscomando extrai as informações do inode e as apresenta para nós em less:
As seguintes informações são mostradas:
- Inode : o número do inode que estamos olhando.
- Tipo : Este é um arquivo normal, não um diretório ou link simbólico.
- Modo : as permissões do arquivo em octal .
- Sinalizadores : 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.
- Usuário : 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 no 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.
- Atime : 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 de 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 : um checksum para este inode, que torna possível detectar se o inode está corrompido.
- Extensões : Se as 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 obtemos o nome do arquivo. É aqui que a estrutura do diretório entra em ação. 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 pode ver os arquivos.
No exemplo a seguir, usaremos ls as opções -l(formato longo), -i(inode) e -d(diretório) e examinaremos o workdiretório:
ls -lid work /
Como usamos a -dopção (diretório), os lsrelatórios sobre o próprio diretório, não seu conteúdo. O inode para este diretório é 1443016.
Para repetir isso para o homediretório, digitamos o seguinte:
ls -lid ~
O inode para o homediretório é 1447510 e o workdiretório está no diretório inicial. Agora, vamos examinar o conteúdo do workdiretório. Em vez da -dopção (diretório), usaremos a -aopção (todos). Isso nos mostrará as entradas do diretório que geralmente estão ocultas.
Nós digitamos o seguinte:
ls -lia trabalho /
Como usamos a -aopçã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 um único ponto, você verá que é 1443016 – o mesmo número do inode que obtivemos quando descobrimos o número do inode para o workdiretório. Além disso, o número do inode para a entrada de ponto duplo é o mesmo que o número do inode para o homediretório.
É por isso que você pode usar o cd ..comando para subir um nível na árvore de diretórios. Da mesma forma, ao preceder um nome de aplicativo ou script com ./, você informa ao shell 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 são na verdade 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 a seguir.
Podemos usar o comando ln e a -sopçã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.shchamado 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 os ->pontos 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, é que o link simbólico,, geek.shnão tem as mesmas permissões de usuário que o arquivo de script original. Na verdade, as permissões para geek.shsão muito mais liberais – todos os usuários têm permissões completas.
A estrutura de diretório de geek.shconté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 de geek.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 geek-appindica que é um link da maneira que a lslista de geek.shfez. Além disso, geek-app 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 geek-appconté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 statprograma para examinar 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 do 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 stat mais uma vez – desta vez em geek-app:
stat geek-app
Esses detalhes são extraídos do mesmo inode (1441797) do statcomando anterior . A contagem de links foi reduzida em um.
Como estamos com apenas um link físico para este inode, se excluirmos geek-app, ele realmente excluirá 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.
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
É necessário um pouco mais de pulos se os dados não forem contíguos.
Imagine o trabalho que deve ser feito para ls realizar uma listagem de arquivos em formato longo de muitos arquivos. Há muitas idas e vindas apenas para lsobter as informações necessárias para gerar sua saída.
É claro que acelerar o acesso ao sistema de arquivos é o motivo pelo qual o Linux tenta fazer o cache de arquivos preventivo o máximo possível. Isso ajuda muito, mas às vezes – como em qualquer sistema de arquivos – as sobrecargas podem se tornar aparentes.
Agora você saberá por quê.
