como posso determinar quantos inodes um diretório usa?

Estamos com um limite de inode em nosso servidor de arquivos e estou fazendo um experimento para reduzir o número de inodes. Como posso descobrir quantos inodes um diretório usa? Eu li que o kernel do linux não cria um inode para links flexíveis com menos de 60 bytes , mas armazena esse link simbólico no próprio inode do diretório. Portanto, estou tentando reduzir o comprimento dos links simbólicos para menos de 60 bytes e ver se isso reduz a contagem de inodes.

EDIT: (não é possível colocar novas linhas nos comentários ...) @caliban O que estou sugerindo é criar 1 link simbólico para o diretório pai e depois fazer com que todos os outros links simbólicos apontem para esse diretório pai, por exemplo, links originais:

a -> /LONG_PATH/a
b -> /LONG_PATH/b
c -> /LONG_PATH/c

com link simbólico do diretório

__parent_dir -> /LONG_PATH
a -> parent_dir/a
b -> parent_dir/b
c -> parent_dir/c

linux inode

— Ross Rogers
fonte

A menos que você tenha muitos links simbólicos no sistema de arquivos, alterá-los não fará muita diferença a longo prazo. Eu morderia a bala e mover alguns ou todos os dados para outro sistema de arquivos assim que você puder reservar algum tempo de manutenção.

— David Spillett

precisamos ter uma ferramenta que gere vários links simbólicos toda vez que uma simulação de hardware é executada. Se pudermos reduzir o uso de inodes dessa ferramenta, provavelmente isso poderá aumentar o desempenho do cache do inode e reduzir o número de inodes.

— 21480 Ross Rogers

Um inode para cada arquivo e diretório, essa é a regra. E sobre a parte em que links simbólicos com menos de 60 bytes são armazenados no próprio inode do diretório ... também acredito que isso esteja errado.

Essencialmente, quando um link simbólico tem menos de 60 bytes, ele é realmente armazenado em seu próprio inode (que é separado do inode do diretório) e um bloco de dados não é criado. Assim, acelera a leitura de links simbólicos com menos de 60 bytes, pois um bloco de dados não precisa ser lido, resultando em operações mais rápidas.

— caliban
fonte

Não é uma pena - ela implica em melhorias de desempenho se você puder manter seus links simbólicos em menos de 60 bytes, pois interrompe uma etapa (sem dúvida lenta) da leitura do bloco de dados. Faça isso, reduza todos para <60bytes! :)

— caliban

Como todos os links simbólicos estão realmente no mesmo diretório, eu criaria um link simbólico que aponta para esse diretório e, em seguida, todos os outros links simbólicos serão relativos a esse diretório. Você acha que isso também melhoraria as coisas? por exemplo, links originais (acima de 100 links) a -> / LONG_PATH / ab -> / LONG_PATH / bc -> / LONG_PATH / c links [...] modificados: _parent -> / LONG_PATH a -> _parent / ab -> _parent / bc -> _parent / c [...]

— Ross Rogers

De acordo com a sua proposição acima, não - na verdade, acho que o desempenho irá regredir se você fizer um link simbólico para um diretório que armazena os outros links simbólicos (pelo que posso entender do seu comentário acima). O melhor é mudar LONG_PATH para o mais curto possível.

— caliban

Isso ocorre porque o link simbólico para esse diretório LONG_PATH será lido, junto com o diretório inode agora, para cada acesso a cada link simbólico individual.

— caliban

Oh não se preocupe! Adoro conversar de qualquer maneira (a SU às vezes é meio metódica e de perguntas e respostas). Sim, ele está armazenado em cache na memória, mas ainda é uma etapa extra para Symlink> Diretório> Symlink. E o sistema sempre precisa analisar esse link simbólico de diretório, caso seja alterado. Sem esse link simbólico para esse diretório, ele passa para Diretório> Link simbólico. Você pode executar algumas ferramentas de análise de desempenho - mas acho que será mais lento.

— caliban