Digamos que você comece com uma folha em branco, ou seja, você não acessou o sistema de arquivos. Agora diga que você executa stat ("/ some / dir / file"). Primeiro, o kernel precisa encontrar o arquivo, que em termos técnicos é chamado de inode. Começa procurando no superbloco do sistema de arquivos, que armazena o inode do diretório raiz. Em seguida, ele abre o diretório raiz, encontra "alguns", abre isso, encontra "dir" etc., eventualmente, encontrando o inode para o arquivo.
Então você precisa realmente ler os dados do inode. Após a primeira leitura, isso também é armazenado em cache na RAM. Portanto, apenas uma leitura precisa acontecer uma vez.
Pense no HD como um toca-discos antigo, quando estiver no lugar certo com a agulha, você poderá continuar lendo as coisas rapidamente enquanto ele gira. No entanto, quando você precisa se mudar para um lugar diferente, chamado de "procurar", está fazendo algo muito diferente. Você precisa mover fisicamente o braço e esperar o prato girar até que o lugar certo esteja embaixo da agulha. Esse tipo de movimento físico é inerentemente lento, portanto, os tempos de busca dos discos são bem longos.
Então, quando procuramos? Depende do layout do sistema de arquivos, é claro. Os sistemas de arquivos tentam armazenar arquivos consecutivamente para aumentar o desempenho da leitura, e geralmente também tentam armazenar inodes para um único diretório próximo, mas tudo depende de coisas como quando os arquivos são gravados, fragmentação do sistema de arquivos etc. Nesse caso, cada estatística de um arquivo fará uma busca e, em seguida, cada abertura do arquivo fará uma segunda busca. Portanto, é por isso que as coisas demoram tanto tempo quando nada é armazenado em cache.
Alguns sistemas de arquivos são melhores que outros, a desfragmentação pode ajudar. Você pode fazer algumas coisas nos aplicativos. Por exemplo, o GIO classifica os inodes recebidos de readdir () antes de declará-los, esperando que o número do inode tenha algum tipo de relação com a ordem do disco (geralmente possui), minimizando assim as buscas aleatórias.
Uma coisa importante é projetar seu armazenamento de dados e aplicativos para minimizar a busca. Por exemplo, é por isso que o Nautilus reading / usr / bin é lento, porque os arquivos lá geralmente não têm extensão, precisamos fazer um sniffing mágico para cada um. Portanto, precisamos abrir cada arquivo => uma busca por arquivo => slooooow. Outro exemplo são os aplicativos que armazenam informações em muitos arquivos pequenos, como o gconf costumava fazer, também uma má idéia. De qualquer forma, na prática, acho que não há muito que você possa fazer, exceto tentar ocultar as latências.