Sistema de arquivos do Linux com inodes próximos no disco

Question

Gostaria de tornar o ls -laR /media/myfs no Linux o mais rápido possível. Eu terei 1 milhão de arquivos no sistema de arquivos, 2TB do tamanho total do arquivo e alguns diretórios contendo até 10000 arquivos. Qual sistema de arquivos devo usar e como devo configurá-lo?

Tanto quanto eu entendo, a razão pela qual ls -laR é lento porque tem stat(2) de cada inode (ou seja, 1 milhão stat(2) s) e como inodes são distribuídos aleatoriamente no disco, cada stat(2) precisa de uma busca de disco.

Aqui estão algumas soluções que eu tinha em mente, nenhuma das quais eu estou satisfeito com:

• Crie o sistema de arquivos em um SSD, porque as operações de busca em SSDs são rápidas. Isso não funcionaria, porque um SSD de 2 TB não existe, ou é proibitivamente caro.

• Crie um sistema de arquivos que abranja dois dispositivos de bloco: um SSD e um disco; o disco contém dados de arquivo e o SSD contém todos os metadados (incluindo entradas de diretório, inodes e atributos estendidos POSIX). Existe um sistema de arquivos que suporta isso? Ele sobreviveria a uma falha no sistema (falta de energia)?

• Use find /media/myfs em ext2, ext3 ou ext4, em vez de ls -laR /media/myfs , porque o primeiro pode ter a vantagem do campo d_type (veja na página getdents(2) man), então não faz t tem que stat. Infelizmente, isso não atende aos meus requisitos, porque também preciso de todos os tamanhos de arquivo, o que find /media/myfs não imprime.

• Use um sistema de arquivos, como o VFAT, que armazena inodes nas entradas do diretório. Eu adoraria esse, mas o VFAT não é confiável e flexível o suficiente para mim, e eu não conheço nenhum outro sistema de arquivos que faça isso. Você? É claro que armazenar inodes nas entradas de diretório não funcionaria para arquivos com um link maior do que 1, mas isso não é um problema, pois tenho apenas algumas dúzias desses arquivos no meu caso de uso.

• Ajuste algumas configurações em /proc ou sysctl para que os inodes sejam bloqueados para a memória do sistema para sempre. Isso não aceleraria o primeiro ls -laR /media/myfs , mas tornaria todas as invocações subsequentes incrivelmente rápidas. Como posso fazer isso? Não gosto dessa ideia, porque não acelera a primeira chamada, que atualmente leva 30 minutos. Também gostaria de bloquear os atributos estendidos POSIX na memória também. O que eu tenho que fazer para isso?

• Use um sistema de arquivos que possui uma ferramenta de desfragmentação online, que pode ser instruída para realocar inodes para o início do dispositivo de bloco. Quando a realocação estiver concluída, posso executar dd if=/dev/sdb of=/dev/null bs=1M count=256 para obter o início do dispositivo de bloco buscado no cache de memória do kernel sem procurar e, em seguida, as operações stat(2) seriam rápidas, porque elas liam no cache. Existe uma maneira de bloquear esses inodes e / ou blocos na memória depois de lidos? Qual sistema de arquivos tem essa ferramenta de desfragmentação?

Answer 1

Trocarei a minha resposta à sua pergunta pela sua resposta: quais botões precisam ser manipulados em / proc ou / sys para manter todos os inodes na memória?

Agora, minha resposta para sua pergunta:

Estou lutando com um problema semelhante, em que estou tentando fazer com que o ls -l funcione rapidamente no NFS para um diretório com alguns milhares de arquivos quando o servidor está sobrecarregado.

A NetApp realiza a tarefa de forma brilhante; tudo o mais que eu tentei até agora não faz.

Pesquisando isso, encontrei alguns sistemas de arquivos que separam metadados de dados, mas todos eles têm algumas deficiências:

• dualfs: Tem alguns patches disponíveis para o 2.4.19, mas não muito mais.
• lustre: ls -l é o pior cenário porque todos os metadados exceto o tamanho do arquivo são armazenados no servidor de metadados.
• QFS para Solaris, StorNext / Xsan: não é conhecido pelo ótimo desempenho de metadados sem um investimento substancial.

Isso não ajudará (a menos que você consiga reviver o dualfs).

A melhor resposta no seu caso é aumentar sua contagem de fusos o máximo possível. A maneira mais feia - mas mais barata e prática - de fazer isso é obter um JBOD de classe empresarial (ou dois) e um cartão de canal de fibra fora do Ebay com alguns anos de idade. Se você olhar duro, você deve ser capaz de manter seus custos abaixo de US $ 500 ou mais. Os termos de pesquisa "146gb" e "73gb" serão de grande ajuda. Você deve ser capaz de convencer um vendedor a fazer um acordo sobre algo assim, já que eles têm um monte deles sentados e quase nenhum comprador interessado:

link

Configure uma faixa RAID-0 em todas as unidades. Faça backup de seus dados religiosamente, porque uma ou duas das unidades inevitavelmente falharão. Use tar para o backup em vez de cp ou rsync, para que a única unidade receptora não tenha que lidar com os milhões de inodes.

Esta é a maneira mais barata que encontrei (neste momento histórico, de qualquer forma) para aumentar os IOPs para sistemas de arquivos na faixa de 2 a 4 TB.

Espero que ajude - ou seja pelo menos interessante!

    

Answer 2

the disk contains file data, and the SSD contains all the metadata ... Is there a filesystem which supports this?

O btrfs suporta isso até certo ponto, btrfs Wiki . Pode-se especificar raid1 para os metadados (e raid0 para dados - a maioria dos dados terminará no HDD grande) para que o SSD tenha sempre uma cópia dos metadados para leitura (não tenho ideia de quão inteligente o btrfs estará na seleção do fonte para leitura de metadados). Eu não vi nenhum benchmark para tal configuração.

    

Answer 3

Nenhuma resposta, infelizmente, embora eu tenha respondido pelo google pela última meia hora.

Create a filesystem which spans on two block devices: an SSD and a disk; the disk contains file data, and the SSD contains all the metadata (including directory entries, inodes and POSIX extended attributes). Is there a filesystem which supports this? Would it survive a system crash (power outage)?

Exatamente o que eu também gostaria.

Para os links, veja este pastebin, porque não tenho permissão para postar mais de um link ...

link

Suporte para vários dispositivos do btrfs é discutido aqui:

Btrfs: Trabalhando com vários dispositivos, por By Jonathan Corbet, 30 de dezembro de 2013 (LWN), [link] [1]

Mas, embora seja possível espelhar os metadados (-m raid1) para um SSD, você é forçado a usar também o SSD para armazenamento de dados (-d raid0), pelo menos parcialmente.

A boa notícia é que há trabalho sendo feito:

Dedicated metadata drives Jan Schmidt and Arne Jansen (Not in kernel yet) We're able to split data and metadata IO very easily. Metadata tends to be dominated by seeks and for many applications it makes sense to put the metadata onto faster SSDs. [link][2]

Se você estiver disposto a usar o General Parallel File System (GPFS) proprietário da IBM, isso já é possível, ao que parece. Leia "Como migrar todos os metadados do sistema de arquivos GPFS para SSDs": [link] [3]

    

Answer 4

Eu apenas usaria ext4 e certifique-se de ter o dir_index definido. Você pode verificar esse sinalizador executando isto:

dumpe2fs /dev/drivepartition | grep "Filesystem features:"

O maior problema que você encontrará é apenas o número de arquivos no sistema de arquivos. Qualquer operação executada no sistema de arquivos terá que examinar cada arquivo. Este é o caso de qualquer sistema de arquivos. 10.000 arquivos em um diretório podem parecer muito, mas eu acho que sistemas de arquivos não ficam lentos até chegar a 40.000 arquivos ou mais e isso é realmente um sintoma mais antigo de sistemas de arquivos como ext2.

Parece que você está tentando fazer algo específico em vez de apenas ter um sistema de arquivos de propósito geral. Se você puder explicar o que está tentando fazer, provavelmente podemos sugerir uma maneira de otimizar seus dados. Por exemplo, um banco de dados.