http://www.zago.eti.br/inodes.txt Use CTRL+F para refinar a pesquisa. Linha de: **************** separa mensagens ou tópicos. ******************************************************** Zago http://www.zago.eti.br/menu.html FAQ e artigos sobre Linux ***************************************************************** i-node é utilizado pelo sistema Linux para alocar os arquivos no sistema, portanto, cada arquivo tem seu i-node e não pode repetir Quando tem muitos arquivos pequenos na partição pode acabar consumindo os i-nodes e impedir de criar novos arquivos, mesmo possuindo espaço disponível em disco vai retornar mensagens relatando que não tem mais espaço em disco, nestas condições verifique se ainda tem i-nodes livres. Verificar inodes, use df -i, ex.: [root@intranet zago]# df -i Sist. Arq. Inodes IUsados ILivr IUso% Montado em /dev/hda2 9764864 311956 9452908 4% / df mostra o espaço livre em disco: [root@intranet zago]# df Sist. Arq. 1K-blocos Usad Dispon. Uso% Montado em /dev/hda2 76794016 65091624 7801408 90% / O resultado acima é de uma instalação do CL10 com sistema de arquivos ext3, agora compare com o resultado abaixo no SUSE10 em sistema raiserfs suse64:~ # mount /dev/sda2 on / type reiserfs (rw,acl,user_xattr) suse64:~ # df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda2 0 0 0 - / tmpfs 59654 2 59652 1% /dev/shm suse64:~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 155335732 4662484 150673248 4% / tmpfs 238616 12 238604 1% /dev/shm Observe que o numero (quantidade) de i-nodes está zerado para a partição /dev/sda2, usando riserfs em uso no "/", mas está utilizando i-nodes para os arquivos, veja o resultado nesta mesma instalação; zago@suse64:/tmp> echo "teste de arquivo" > arqteste.txt zago@suse64:/tmp> ls -i arqteste.txt 117328 arqteste.txt Parece confuso mas deve algo relacionado ao sistema de arquivos no tratamento e uso do i-node, isto depende do sistema de arquivos. O principio em sistemas ext2 e ext3, o sistema operacional utiliza o i-node como identificação do arquivo, partindo deste principio, em condições normais não existe dois arquivos no mesmo sistema utilizando o mesmo i-node, exceto no caso de hard-link, veja este exemplo onde o hard-link aponta para o mesmo i-node do arquivo; zago@suse64:/tmp> echo "teste de arquivo" > arqteste.txt zago@suse64:/tmp> ls -i arqteste.txt 117328 arqteste.txt zago@suse64:/tmp> ln arqteste.txt /tmp/link-arqteste.txt zago@suse64:/tmp> ls -i arqteste.txt link-arqteste.txt 117328 arqteste.txt 117328 link-arqteste.txt Não pode existir dois arquivos com o mesmo i-node mas com hard-link ocorre esta situação. Considere que lidar com hard-link é a mesma coisa de lidar com o arquivo, quando apaga um arquvo o outro também deixa de existir, o interessante neste caso é que existem dois arquivos no sistema com o mesmo i-node, ao apagar este i-node acaba apagando os dois aquivos, o principal e o hard-link. Pode localizar o arquivo pelo i-node, precisa conhece-lo antes, como no exemplo acima, usando o mesmo i-node acima, para localizar com find use neste formato. find / -inum 117328 apagar, remover arquivos pelo i-node em lugar do nome, veja exemplo. find / -inum 117328 -exec rm - {} \; ***************************************************************** o comando para listar os inodes eh "ls -lai", veja: 1662985 drwx------ 6 crash users 1024 Jun 21 11:39 . 1656841 drwx------ 11 crash users 1024 Jun 28 21:51 .. 1656899 -rw-r--r-- 1 crash users 1709589 May 19 19:24 apache_1.3.12.tar.gz 1663020 -rw-r--r-- 1 crash users 1251509 May 16 14:13 bind-8.2.2-src.tar.gz | | | -> A -> B -> C onde: A-> endereco do inodo inicial do arquivo (onde encontra-se os descritores, blobo inicial, bloco final, nome ascii, permissoes, etc..); B-> idem a sua descricao; C-> tamanho do arquivo em kbytes; ***************************************************************** para mostrar os inodes, use a opção '-i' do ls: $ ls -li la* 2322141 -rw-rw-r-- 2 eliphas eliphas 0 Jun 28 18:15 la 2322141 -rw-rw-r-- 2 eliphas eliphas 0 Jun 28 18:15 lala 2322147 lrwxrwxrwx 1 eliphas eliphas 2 Jun 28 18:16 lalala -> la ^ inode ***************************************************************** Deve existir boa documentacao sobre isso na Internet. Esse esquema de inode e' algo que foi bolado desde o inicio do Unix, possivelmente copiado de outros sistemas. Uma das possibilidades do inode e' permitir que o nome do arquivo seja usado para organizar a informacao no disco, sem que isso represente aumento no consumo de espaco de armazenamento. Um programa pode fazer duas coisas diferentes se tiver nomes diferentes, como o gzip e gunzip. Voce pode criar uma organizacao de documentos em diretorios e permitir que /doc/internet/redes e /doc/redes/internet aponte para o mesmo aquivo, sem que isso aumente o espaco em disco. Existem vantagens tambem com relacao ao fato de que a separacao permite que tasks possam usar os arquivos independentemente da organizacao dos diretorios. Na verdade e' essa a enorme vantagem que o uso de inodes oferece e o motivo de sua adocao. Imagine a situacao usual no syslogd (o programa que loga as mensagens em /var/log/messages). Essa task roda permanentemente e oferece o servico de syslog para qualquer programa que deseja usa-lo. E' um servico que nao deve ser interrompido. Quando o syslogd abre o /var/log/messages ele abre o inode associado e nao mais se preocupa com o nome ou diretorio. Imagine que o administrador precisa criar um novo arquivo (comecar o messages de novo) e salvar o arquivo anterior para o backup. O syslogd esta' escrevendo no arquivo, e normalmente em servidores 24/7 existem outros programas analisando o arquivo /var/log/messages. Como fazer isso sem interromper o servico? Com o uso de inodes primeiro se renomeia o arquivo messages, e isso nao muda o inode, portanto os programas continuam a funcionar normalmente. Em seguida faz-se um "kill -HUP" no syslogd que fecha o inode do antigo arquivo messages e cria um novo arquivo messages, que vai alocar um novo inode. Isso nao interrompe em absoluto o servico de syslog. Os programas que estavam usando o arquivo messages antigo vao concluir a operacao usando o inode antigo sem serem incomodados. Se sao programas que rodam permenentemente, basta estarem preparados para reconhecer "kill -HUP" para fechar o inode antigo e abrir o arquivo messages novamente, e com isso tambem poderao continuar a funcionar sem a menor interrupcao. Se o administrador desejar deletar o arquivo messages antigo, isso nao vai afetar os programas que estao lendo esse arquivo. Cada inode tem um contador de "links" que ele tem no filesystem, isto e', quantos nomes de arquivos estao usando este inode. Quando deletamos um arquivo na verdade estamos removendo um link, decrementando o contador de links do inode, e por isso que nao existe "delete" em filesystem Unix, e sim "unlink". Quando um inode tem link igual a zero __E__ nenhuma task esta' usando o inode no momento, entao o arquivo pode ser removido (os data blocks voltam a ser free blocks e o inode volta a ficar disponivel para ser reusado). Existem varias outras situacoes num ambiente multitask em que o uso de inodes mostra vantagens indispensaveis. Em Unix, a funcao "rename" do kernel (usado pelo mv) e' __garantidamente__ "atomic" quando o arquivo de destino ja existe (e sera' substituido). Isso garante que nenhuma task fai ficar na mao enquanto o rename e' realizado: ou a task usa o inode antigo ou usa o inode novo. A funcao link associa um novo nome ao inode de outro arquivo e tambem e' "atomic". Essa funcao do filesystem e' usada por varios programas para evitar que dois programas facam uma mesma operacao simultaneamente, quando apenas um pode realizar uma determinada tarefa num mesmo instante. Isso e' chamado "esquema de bloqueio" (lock) usando "lock files". O esquema normalmente e': criar um arquivo temporario; fazer um link desse arquivo para o arquivo de lock; link com sucesso? (falha se o arquivo de lock ja' existir) sim -> a task e' tem o lock para si', pode fazer a operacao nao -> a task deve parar, ou esperar um pouco e tentar novamente; unlink no arquivo de lock; Os arquivos em /var/run e em /var/lock tem essa funcao. E' praxe tambem colocar nesses arquivos o PID da task corrente. Com isso pode-se saber qual a task que esta' realizando o servico e tambem permite eliminar "dead locks", isto e', eliminar o lockfile "esquecidos" caso a task que criou o lockfile nao esta' mais rodando. --- Wagner wks@niktu.psi.com.br ***************************************************************** ***************************************************************** ***************************************************************** ***************************************************************** *****************************************************************