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

O Linux tem o mesmo "problema". Aqui é um trabalho um estudante meu publicado há dois anos, onde o efeito é mostrado no Linux . Os vários pedidos de veiculação podem ter várias origens:

• Pesquisa de diretório em cada nível de diretório do caminho do arquivo. Pode ser necessário ler o diretório inode e um ou mais blocos de entradas de diretório
• Inode do arquivo

No padrão normal de IO, o armazenamento em cache é realmente efetivo e inodes, diretórios e blocos de dados são alocados de maneira a reduzir buscas. No entanto, o método de pesquisa normal, que na verdade é compartilhado por todos os sistemas de arquivos, é ruim para o tráfego altamente aleatório.

Aqui estão algumas ideias:

1) Os caches relacionados ao sistema de arquivos ajudam. Um cache grande absorverá a maioria das leituras. No entanto, se você quiser colocar vários discos em uma máquina, a proporção de disco para RAM limita o quanto é armazenado em cache.

2) Não use milhões de arquivos pequenos. Agregue-os a arquivos maiores e armazene o nome do arquivo e o deslocamento dentro do arquivo.

3) Coloque ou armazene em cache os metadados em um SSD.

4) E, claro, usar um sistema de arquivos que não tenha um formato de diretório totalmente anárquico no disco. Um readdir não deve demorar mais do que o tempo linear, e direcionar o acesso a arquivos idealmente apenas no tempo logarítmico.

Manter diretórios pequenos (menos de 1000) não deve ajudar muito, porque você precisaria de mais diretórios com necessidade de armazenamento em cache.

    

Answer 2

Isso depende do sistema de arquivos que você planeja usar. Antes de ler o sistema de dados de arquivo:

• Leia o arquivo de diretório.
• Leia o inode do seu arquivo
• Leia setores do seu arquivo

Se a pasta contiver um grande número de arquivos, isso é uma grande garantia no cache.

    

Answer 3

Você provavelmente não conseguirá manter todos os dados de diretório e inode na RAM, pois você provavelmente terá mais dados de diretório e inode do que a RAM. Você também pode não querer, pois essa RAM pode ser melhor usada para outros propósitos; no seu exemplo de imagem, você não preferiria ter os dados de uma imagem acessada com freqüência em cache na RAM do que a entrada de diretório para uma imagem acessada com pouca frequência?

Dito isso, acho que o botão vfs_cache_pressure é usado para controlar isso. "Quando vfs_cache_pressure = 0, o kernel irá nunca recupere dentaduras e inodes devido à pressão da memória e isso pode facilmente levar a condições de falta de memória. "