in

Red Hat trabalha em um novo sistema de arquivos NVFS

Desempenho se mostrou muito mais rápido.

Red Hat Enterprise Linux 7.9 é a última atualização do RHEL 7

A Red Hat trabalha em um novo sistema de arquivos NVFS, considerado mais eficiente para NVM. Mikuláš Pato?ka, um dos desenvolvedores LVM e inventor de várias otimizações de armazenamento na Red Hat, introduziu o novo sistema de arquivo NVFS na lista de discussão do kernel Linux.

Este novo sistema visa a criar um sistema de arquivos rápido e compacto para chips de memória não voláteis (NVM, por exemplo NVDIMM), combinando o desempenho da RAM com a capacidade de armazenar conteúdo permanentemente.

No desenvolvimento do NVFS foi levada em consideração a experiência do FS NOVA, criado em 2017 especificamente para memória NVM, mas não incluído no kernel Linux e com suporte limitado para kernels Linux de 4.13 a 5.1.

O NVFS FS proposto é muito mais simples que o NOVA (4972 linhas de código vs 21459), fornece um utilitário fsck, tem melhor desempenho, oferece suporte a atributos estendidos (xattrs), rótulos de segurança, ACLs e cotas, mas não dá suporte a instantâneos.

A arquitetura NVFS é próxima ao FS Ext4 e se encaixa bem no modelo de sistema de arquivos baseado em subsistema VFS, tornando possível minimizar o número de camadas intermediárias e sobreviver com um módulo que não requer patches de kernel.

Red Hat trabalha em um novo sistema de arquivos NVFS

Red Hat trabalha em um novo sistema de arquivos NVFS

O NVFS usa a interface de kernel DAX para acessar diretamente dispositivos de armazenamento persistente, ignorando o cache de página. Para otimizar o trabalho com a memória NVM, que usa endereçamento de bytes, o conteúdo da unidade é mapeado para o espaço de endereço linear do kernel sem usar a camada de dispositivo de bloco tradicional e o cache intermediário. É usado para armazenar o conteúdo dos diretórios da árvore raiz, em que cada nome de arquivo e valor de hash é usado para pesquisar a árvore.

A integridade dos dados é garantida através do mecanismo de “atualizações” (como no FreeBSD UFS e no OpenBSD FFS) sem usar o diário.

Para evitar a corrupção de arquivos no NVFS, as operações de alteração de dados são agrupadas de forma que uma falha não possa levar à perda de blocos ou inodes, e a integridade das estruturas seja restaurada usando o utilitário fsck.

Os números

O utilitário fsck é multithread e fornece um desempenho de força bruta de 1,6 milhão de inodes por segundo.

  • Em benchmarks, NVFS executou uma operação de cópia de árvore com fontes de kernel Linux na memória NVM aproximadamente 10% mais rápido que o NOVA, 30% mais rápido que ext4 e 37% mais rápido que XFS.
  • No teste de pesquisa de dados, o NVFS foi mais rápido do que o NOVA em 3% e o ext4 e o XFS em 15% (mas com um cache de disco ativo, o NOVA foi 15% mais lento).
  • No teste de Million Directory Operations, o NVFS superou o NOVA em 40%, o ext4 em 22% e o XFS em 46%. Ao simular a atividade do DBMS, o sistema de arquivos NVFS superou o NOVA em 20%, o ext4 em 18 vezes e o XFS em 5 vezes. No teste fs_mark, NVFS e NOVA foram praticamente os mesmos, enquanto ext4 e XFS ficaram cerca de 3 vezes atrás.

Motivo da rapidez

O atraso dos FSs tradicionais na memória NVM se deve ao fato de que eles não foram projetados para o endereçamento de bytes usado na memória não volátil, que se assemelha à RAM normal.

A leitura normal da unidade fornece atomicidade de operação no nível de leitura/gravação do setor, enquanto a memória NVM fornece acesso no nível de palavra de máquina individual.

Além disso, os sistemas de arquivos tradicionais tentam reduzir a intensidade do acesso à mídia, que é obviamente considerado mais lento do que a RAM, e também tentam agrupar operações para garantir leituras sequenciais ao usar discos rígidos, processar filas de solicitação, combater a fragmentação e prioridades separadas para executar operações diferentes.

Para a memória NVM, tais complicações são desnecessárias, pois a velocidade de acesso aos dados é comparável à da RAM.

Para mais informações, consulte o link: https://lkml.org/lkml/2020/9/15/517