Linux: quantas E / S de disco são necessárias para ler um arquivo? Como minimizar isso?

Question

De acordo com este artigo no Haystack do Facebook:

"Because of how the NAS appliances manage directory metadata, placing thousands of files in a directory was extremely inefficient as the directory’s blockmap was too large to be cached effectively by the appliance. Consequently it was common to incur more than 10 disk operations to retrieve a single image. After reducing directory sizes to hundreds of images per directory, the resulting system would still generally incur 3 disk operations to fetch an image: one to read the directory metadata into memory, a second to load the inode into memory, and a third to read the file contents."

Eu tinha assumido os metadados e & inode sempre seria armazenado em cache na RAM pelo SO e uma leitura de arquivo normalmente exigiria apenas 1 IO de disco.

Este problema de "vários E / S de disco para ler um único arquivo" descrito nesse documento é exclusivo dos dispositivos NAS, ou o Linux também tem o mesmo problema?

Estou planejando executar um servidor Linux para veicular imagens. De qualquer forma, posso minimizar o número de IO de disco - idealmente, certificando-se de que o sistema operacional armazena em cache todo o diretório & dados de inode na RAM e cada leitura de arquivo requer apenas não mais que 1 IO de disco?

    

Answer 1

Isso depende do sistema de arquivos sendo usado. Alguns sistemas de arquivos são melhores no problema de diretório grande do que os outros, e sim o armazenamento em cache afeta o uso.

Versões mais antigas do EXT3 tiveram um problema muito ruim ao lidar com diretórios com milhares de arquivos neles, o que foi corrigido quando os dir_indexes foram introduzidos. Se um dir_index não for usado, recuperar um arquivo de um diretório com milhares de arquivos pode ser muito caro. Sem saber os detalhes, suspeito que é o que o dispositivo NAS no artigo estava usando.

Sistemas de arquivos modernos (o mais recente ext3, ext4, xfs) lidam com problemas muito maiores do que antigamente. Alguns inodes podem ficar grandes, mas as árvores b em uso comum para indexar os diretórios são muito rápidas em fopen times.

    

Answer 2

I had assumed the filesystem directory metadata & inode would always be cached in RAM

Sim, mas você não aprendeu a ler corretamente. No parágrafo que você mesmo citou, diz claramente:

Because of how the NAS appliances manage directory metadata, placing thousands of files in a directory was extremely inefficient as the directory’s blockmap was too large to be cached effectively by the appliance.

Os aparelhos são harwdware de baixo custo. Muitos metadados + pouca RAM = NENHUMA MANEIRA DE CACHE IT.

Se você executar um servidor de arquivos grande, adquira um, não um appliance de baixo custo.

    

Answer 3

Se você pode viver sem tempos de acesso atualizados sobre arquivos e diretórios, você pode salvar um monte de pedidos de E / S se você montar um sistema de arquivos com a opção 'noatime'.

    

Answer 4

Isso é feito por padrão no Linux. Se você tiver uma boa quantidade de RAM, obterá um bom cache.

    

Answer 5

É sobre uma medição cuidadosa. Se você tem como objetivo servir imagens, acho que seu tráfego de rede seria dominado por elas. Além disso, se você não estiver fazendo o cache, as taxas de disco devem se aproximar das taxas de rede. Finalmente, se você estiver fazendo um cache perfeito, as taxas de rede permaneceriam as mesmas e as taxas de disco iriam para 0.

Em outras palavras, meça tudo! Eu uso collectl exclusivamente para isso, assim como muitos dos usuários de alguns dos maiores clusters do mundo.

Basta fazer o download / instalar e iniciá-lo. Ele irá registrar uma tonelada de coisas que você pode reproduzir ou até mesmo traçar. Em seguida, analise os números e descubra com que eficiência seu cache está funcionando.

-mark