inode - inode

O inode (nó de índice) é uma estrutura de dados em um sistema de arquivos no estilo Unix que descreve um objeto do sistema de arquivos , como um arquivo ou diretório . Cada inode armazena os atributos e as localizações dos blocos de disco dos dados do objeto. Os atributos do objeto do sistema de arquivos podem incluir metadados (horários da última alteração, acesso, modificação), bem como dados de proprietário e permissão .

Um diretório é uma lista de inodes com seus nomes atribuídos. A lista inclui uma entrada para ela mesma, seu pai e cada um de seus filhos.

Etimologia

Há incertezas na lista de discussão do kernel do Linux sobre o motivo do "i" em "inode". Em 2002, a pergunta foi trazida ao pioneiro do Unix Dennis Ritchie , que respondeu:

Na verdade, também não sei. Foi apenas um termo que começamos a usar. "Índice" é meu melhor palpite, por causa da estrutura do sistema de arquivos um pouco incomum que armazenava as informações de acesso dos arquivos como uma matriz plana no disco, com todas as informações do diretório hierárquico vivendo além disso. Assim, o i-número é um índice neste array, o i-node é o elemento selecionado do array. (A notação "i-" foi usada na 1ª edição do manual; seu hífen foi gradualmente eliminado.)

Um artigo de 1978 por Ritchie e Ken Thompson reforça a noção de "índice" como a origem etimológica dos inodes. Eles escreveram:

[…] Uma entrada de diretório contém apenas um nome para o arquivo associado e um ponteiro para o próprio arquivo. Este ponteiro é um número inteiro denominado número-i (para número de índice) do arquivo. Quando o arquivo é acessado, seu número-i é usado como um índice em uma tabela do sistema (a lista-i ) armazenada em uma parte conhecida do dispositivo no qual o diretório reside. A entrada encontrada assim (o i-node do arquivo ) contém a descrição do arquivo.

Além disso, Maurice J. Bach escreveu que um inode "é uma contração do termo nó de índice e é comumente usado na literatura no sistema UNIX".

Detalhes

Descritores de arquivo, tabela de arquivo e tabela de inode no Unix

Um sistema de arquivos depende de estruturas de dados sobre os arquivos, em oposição ao conteúdo desse arquivo. Os primeiros são chamados de metadados - dados que descrevem os dados. Cada arquivo está associado a um inode , que é identificado por um número inteiro, geralmente referido como um número i ou número de inode .

Os inodes armazenam informações sobre arquivos e diretórios (pastas), como propriedade do arquivo, modo de acesso (permissões de leitura, gravação e execução) e tipo de arquivo. Em muitas implementações de sistema de arquivos mais antigas, o número máximo de inodes é fixado na criação do sistema de arquivos, limitando o número máximo de arquivos que o sistema de arquivos pode conter. Uma heurística de alocação típica para inodes em um sistema de arquivos é um inode para cada 2K bytes contidos no sistema de arquivos.

O número de inode indexa uma tabela de inodes em um local conhecido no dispositivo. A partir do número do inode, o driver do sistema de arquivos do kernel pode acessar o conteúdo do inode, incluindo a localização do arquivo, permitindo assim o acesso ao arquivo. O número de inode de um arquivo pode ser encontrado usando o ls -icomando. O ls -icomando imprime o número do nó i na primeira coluna do relatório.

Alguns sistemas de arquivos no estilo Unix, como ReiserFS , btrfs e APFS, omitem uma tabela inode de tamanho fixo, mas devem armazenar dados equivalentes para fornecer recursos equivalentes. Os dados podem ser chamados de dados estatísticos, em referência à stat chamada do sistema que fornece os dados aos programas. Alternativas comuns para a mesa de tamanho fixo incluem árvores B e as árvores B + derivadas .

Nomes de arquivos e implicações de diretório:

  • Os inodes não contêm seus nomes de hardlink, apenas outros metadados de arquivo.
  • Os diretórios Unix são listas de estruturas de associação, cada uma contendo um nome de arquivo e um número de inode.
  • O driver do sistema de arquivos deve pesquisar um diretório procurando um nome de arquivo específico e, em seguida, converter o nome do arquivo para o número de inode correspondente correto.

A representação na memória do kernel do sistema operacional desses dados é chamada struct inodeno Linux . Os sistemas derivados do BSD usam o termo vnode(o "v" refere-se à camada de sistema de arquivo virtual do kernel ).

Descrição do inode POSIX

O padrão POSIX determina o comportamento do sistema de arquivos que é fortemente influenciado pelos sistemas de arquivos UNIX tradicionais . Um inode é denotado pela frase "número de série do arquivo", definido como um identificador exclusivo por sistema de arquivo para um arquivo. Esse número de série do arquivo, junto com o ID do dispositivo que contém o arquivo, identifica o arquivo de forma exclusiva em todo o sistema.

Em um sistema POSIX, um arquivo possui os seguintes atributos que podem ser recuperados pela statchamada do sistema:

  • ID do dispositivo (identifica o dispositivo que contém o arquivo; ou seja, o escopo de exclusividade do número de série).
  • Números de série do arquivo.
  • O modo de arquivo que determina o tipo de arquivo e como o proprietário do arquivo, seu grupo e outros podem acessar o arquivo.
  • Uma contagem de links informando quantos links físicos apontam para o inode.
  • A ID de usuário do proprietário do arquivo.
  • O ID de grupo do arquivo.
  • O ID do dispositivo do arquivo, se for um arquivo de dispositivo .
  • O tamanho do arquivo em bytes .
  • Timestamps informando quando o próprio inode foi modificado pela última vez ( ctime , inode change time ), o conteúdo do arquivo modificado pela última vez ( mtime , hora da modificação ) e o último acesso ( atime , hora de acesso ).
  • O tamanho de bloco de E / S preferido.
  • O número de blocos alocados para este arquivo.

Implicações

Os sistemas de arquivos projetados com inodes terão as seguintes características administrativas.

  • Os arquivos podem ter vários nomes. Se vários nomes forem vinculados ao mesmo inode, os nomes serão equivalentes; ou seja, o primeiro a ser criado não tem um status especial. Isso é diferente de links simbólicos , que dependem do nome original, não do inode (número).
  • Um inode pode não ter links. Um arquivo desvinculado é removido do disco e seus recursos são liberados para realocação, mas a exclusão deve esperar até que todos os processos que o abriram terminem de acessá-lo. Isso inclui arquivos executáveis ​​que são implicitamente mantidos abertos pelos processos que os executam.
  • Normalmente não é possível mapear de um arquivo aberto para o nome de arquivo que foi usado para abri-lo. O sistema operacional converte imediatamente o nome do arquivo em um número de inode e, em seguida, descarta o nome do arquivo. Isso significa que as funções de biblioteca getcwd () e getwd () pesquisam o diretório pai para encontrar um arquivo com um inode que corresponda ao diretório de trabalho , depois pesquisam o pai desse diretório e assim por diante até chegar ao diretório raiz . Os sistemas SVR4 e Linux mantêm informações extras para tornar isso possível.
  • Historicamente, era possível criar links físicos para diretórios. Isso transformou a estrutura de diretórios em um gráfico direcionado arbitrário, ao contrário de um gráfico acíclico direcionado . Era até possível que um diretório fosse seu próprio pai. Os sistemas modernos geralmente proíbem esse estado confuso, exceto que o pai do root ainda é definido como root. A exceção mais notável a essa proibição é encontrada no Mac OS X (versões 10.5 e superior), que permite que links físicos de diretórios sejam criados pelo superusuário.
  • O número de inode de um arquivo permanece o mesmo quando ele é movido para outro diretório no mesmo dispositivo, ou quando o disco é desfragmentado, o que pode mudar sua localização física, permitindo que ele seja movido e renomeado mesmo enquanto é lido e gravado sem causar interrupção . Isso também implica que o comportamento do inode em conformidade total é impossível de implementar com muitos sistemas de arquivos não-Unix, como FAT e seus descendentes, que não têm uma maneira de armazenar essa invariância quando a entrada do diretório de um arquivo e seus dados são movidos .
  • A instalação de novas bibliotecas é simples com sistemas de arquivos inode. Um processo em execução pode acessar um arquivo de biblioteca enquanto outro processo substitui esse arquivo, criando um novo inode, e um novo mapeamento existirá para o novo arquivo para que as tentativas subsequentes de acessar a biblioteca obtenham a nova versão. Este recurso elimina a necessidade de reinicializar para substituir as bibliotecas mapeadas no momento.
  • É possível que um dispositivo fique sem inodes. Quando isso acontece, não é possível criar novos arquivos no dispositivo, mesmo que haja espaço livre disponível. Isso é mais comum para casos de uso como servidores de e-mail que contêm muitos arquivos pequenos. Os sistemas de arquivos (como JFS ou XFS ) escapam dessa limitação com extensões ou alocação dinâmica de inodes, que pode "aumentar" o sistema de arquivos ou aumentar o número de inodes.

Inlining

Pode fazer sentido armazenar arquivos muito pequenos no próprio inode para economizar espaço (nenhum bloco de dados necessário) e tempo de pesquisa (não é necessário mais acesso ao disco). Este recurso do sistema de arquivos é denominado embutido. A separação estrita de inode e dados de arquivo, portanto, não pode mais ser assumida ao usar sistemas de arquivos modernos.

Se os dados de um arquivo caberem no espaço alocado para ponteiros para os dados, este espaço pode ser usado convenientemente. Por exemplo, ext2 e seus sucessores armazenam os dados de links simbólicos (normalmente nomes de arquivos) desta forma se os dados não tiverem mais de 60 bytes ("links simbólicos rápidos").

Ext4 tem uma opção de sistema de arquivo chamada inline_dataque permite ext4 executar inlining se habilitado durante a criação do sistema de arquivo. Como o tamanho de um inode é limitado, isso só funciona para arquivos muito pequenos.

Em sistemas não Unix

  • O NTFS tem uma tabela de arquivos mestre (MFT) que armazena arquivos em uma árvore B. Cada entrada possui um "fileID", análogo ao número do inode, que se refere exclusivamente a esta entrada. Os três carimbos de data / hora, um ID de dispositivo, atributos, contagem de referência e tamanhos de arquivo são encontrados na entrada, mas ao contrário do POSIX, as permissões são expressas por meio de uma API diferente. O layout do disco é mais complexo. Os sistemas de arquivos FAT anteriores não tinham essa tabela e eram incapazes de fazer links físicos .
    • O NTFS também tem um conceito de inserir arquivos pequenos na entrada MFT.
    • O ReFS derivado tem um MFT homólogo. ReFS tem um ID de arquivo de 128 bits; essa extensão também foi portada para NTFS, que originalmente tinha uma ID de arquivo de 64 bits.
  • A mesma API GetFileInformationByHandle semelhante a estatísticas pode ser usada em Cluster Shared Volumes e SMB 3.0 , portanto, esses sistemas presumivelmente têm um conceito semelhante de um ID de arquivo.

Veja também

Referências

links externos