O que são inodes bons para?

Question

Gostaria de saber se armazenar as informações sobre arquivos em inodes em vez de diretamente no diretório vale a pena a sobrecarga adicional. Pode ser que eu esteja superestimando a sobrecarga ou negligenciando alguma coisa importante, mas é por isso que estou perguntando.

Eu vejo que algo como "inodes" é necessário para hardlinks, mas no caso da sobrecarga é realmente tão grande quanto eu penso, pergunto-me se qualquer uma das razões justifica:

• o uso de hardlinks para backups é inteligente, mas a eficiência dos backups não é importante o suficiente quando comparada à eficiência das operações normais
• não tendo nem velocidade nem penalidade de tamanho para hardlinks pode realmente importar, já que essa vantagem vale apenas para os poucos arquivos fazendo uso de hardlinks enquanto o acesso a todos os arquivos sofre o sobrecarga
• economizando espaço para alguns binários com nomes iguais, como bunzip2 e bcat insignificantes

Não estou dizendo que inodes / hardlinks são ruins ou inúteis, mas podem justificar o custo da indireção extra (o armazenamento em cache ajuda certamente muito, mas não é uma bala de prata)?

    

Answer 1

Hard links são além do ponto. Eles não são o motivo para ter inodes. Eles são um subproduto: basicamente, qualquer design de sistema de arquivos razoável semelhante a um unix (e até mesmo o NTFS está próximo o suficiente neste ponto) tem links físicos de graça.

O inode é onde todos os metadados de um arquivo são armazenados: sua hora de modificação, suas permissões e assim por diante. É também onde a localização dos dados do arquivo no disco é armazenada. Esses dados devem ser armazenados em algum lugar.

Armazenar os dados do inode dentro do diretório carrega sua própria sobrecarga. Isso torna o diretório maior, para que a obtenção de uma listagem de diretório seja mais lenta. Você salva uma busca para cada acesso de arquivo, mas cada passagem de diretório (dos quais vários são necessários para acessar um arquivo, um por diretório no caminho do arquivo) custa um pouco mais. Mais importante ainda, torna muito mais difícil mover um arquivo de um diretório para outro: em vez de mover apenas um ponteiro para o inode, você precisa mover todos os metadados.

Os sistemas Unix sempre permitem renomear ou excluir um arquivo, mesmo se um processo o tiver aberto. (Em algumas variantes unix, faça isso quase sempre.) Essa é uma propriedade muito importante na prática: significa que um aplicativo não pode “seqüestrar” um arquivo. Renomear ou remover o arquivo não afeta o aplicativo, ele pode continuar lendo e gravando no arquivo. Se o arquivo for excluído, os dados permanecerão até que nenhum processo abra o arquivo. Isso é facilitado pela associação do processo com o inode. O processo não pode ser associado ao nome do arquivo, pois isso pode mudar ou até mesmo desaparecer a qualquer momento.

Veja também O que é um Superblock, Inode, Dentry e um arquivo?

    

Answer 2

Você pode ter perdido alguns outros fatores. A separação do inode do nome do arquivo em um diretório permite links rígidos, mas duvido que os hard links constituam a única motivação, ou mesmo a original, para essa separação.

Eu tenho uma cópia do "The Bell System Technical Journal", julho-agosto de 1978. Este é um dos seus problemas especiais, e é intitulado "Unix Time Sharing System". Esse é o lugar onde Thompson, Ritchie e companhia publicaram sua descrição da versão 6 e 7 do Unix, e o que você poderia fazer com isso.

Eu vejo descrições de inodes e do sistema de arquivos, mas sem motivações para o design. Ritchie e Thompson observam que uma chamada de sistema create (sua grafia no BSTJ) faz o inode e define os valores, enquanto open chamadas do sistema preenchem as tabelas do SO que podem conter dados de inode em acessos de arquivo adicionais. / p>

Um dos parágrafos principais fala sobre o pedaço de disco que contém inodes, que eles chamaram de i-list:

A noção de i-list é um recurso incomum do UNIX. Na prática, esse método de organizar o sistema de arquivos provou ser bastante confiável e fácil de lidar. ... Ele também permite um algoritmo bastante simples e rápido para verificar a consistência de um sistema de arquivos, ... Este algoritmo é independente da hierarquia do diretório, porque ele precisa apenas varrer a lista de opções organizada linearmente.

Os designers originais descobriram que manter os inodes separados dos dados tornava as coisas mais confiáveis.

Eu acredito que podemos apontar anos de experiência para tornar isso verdade. O MS-DOS e outros sistemas de arquivos nos quais a hierarquia de diretórios está toda misturada com a alocação (FAT) são bastante frágeis. Se um setor do FAT vai mal, as coisas são realmente difíceis de recuperar. Mas se um setor em um diretório for mal, então o inode, em algum outro lugar no disco, ainda estará por aí, com uma contagem de links que indica que ele pertence a algum diretório e, portanto, pode ser recuperado.

Parece que talvez a sobrecarga óbvia de procurar em um diretório por um número de inode e, em seguida, procurar permissões ou dados no inode seja compensada tornando o gerenciamento de arquivos do SO mais simples ou com maior confiabilidade.

    

Answer 3

1 exemplo inode prático:

você tem um arquivo com um nome complicado (exemplo ~ *) e precisa excluí-lo.

ls
~*

rm -rf ~* danifica seu $ HOME, então você precisa excluí-lo de outra maneira.

Leia aqui como excluir arquivos por inode.

Excluir arquivo por inode:

find . -type f -inum 1234 - exec rm -rf {} /;

ok, eu sei que você pode escapar dos caracteres especiais e simplesmente deletá-lo com rm, ou usar o truque, mas ainda assim.

    

Answer 4

Os links físicos não são usados apenas para arquivos; . é um link real no sistema de arquivos, portanto, cada diretório possui pelo menos dois links do sistema de arquivos - seu caminho completo e o link . . Adicione os links .. e um diretório pode ter muitos links físicos.