Desabilitando as barreiras de escrita ext4 ao usar um diário externo

Question

Atualmente, estou experimentando diferentes maneiras de melhorar a velocidade de gravação em um array de software-raid (mdadm) rotacional baseado em disco e bastante grande no Debian usando dispositivos NVMe rápidos.

Eu encontrei que usar um par desses dispositivos (raid1, espelhado) para armazenar o diário do sistema de arquivos produz um desempenho interessante benefícios. As opções de montagem que estou usando para conseguir isso são noatime,journal_aync_commit,data=journal .

Em meus testes, também descobri que adicionar a opção barrier=0 oferece benefícios significativos em termos de desempenho de gravação. No entanto, não tenho certeza de que essa opção seja segura para uso em minha configuração específica do sistema de arquivos. Isto é o que a documentação do kernel diz sobre as barreiras de escrita ext4:

Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.

O dispositivo NVMe específico que estou usando é um Intel DC P3700 que possui proteção de perda de energia integrada, o que significa que, no caso de um desligamento inesperado, qualquer dado ainda presente em buffers temporários é comprometido com segurança com armazenamento NAND graças ao armazenamento de energia de reserva .

Então, minha pergunta é: posso desativar com segurança as barreiras de escrita do ext4 se o diário estiver armazenado em um dispositivo com cache de bateria, enquanto o restante do próprio sistema de arquivos fica em discos que não possuem esse recurso?

    

Answer 1

Estou escrevendo uma nova resposta porque, depois de uma análise mais detalhada, não acredito que a resposta anterior esteja correta.

Se observarmos a função write_dirty_buffers , ela emitirá uma solicitação de gravação com o sinalizador REQ_SYNC , mas não fará com que uma liberação ou barreira do cache seja emitida. Isso é realizado pela blkdev_issue_flush chamada , que é adequadamente protegida por uma verificação da JDB2_BARRIER flag, que por si só é presente apenas quando o sistema de arquivos é montado com barreiras ativadas .

Portanto, se olharmos para checkpoint.c , as barreiras só importam quando uma transação é descartada do diário. Os comentários no código são informativos aqui, dizendo que É improvável que essa barreira de escrita seja necessária, mas existe de qualquer maneira como uma salvaguarda. Acho que a suposição aqui é que, no momento em que uma transação é descartada da revista, é improvável que os dados permaneçam no cache da unidade e ainda não estejam comprometidos com o armazenamento permanente. Mas como é apenas uma suposição, a barreira de gravação é emitida de qualquer maneira.

Então, por que as barreiras não são usadas ao gravar dados no sistema de arquivos principal? Acho que a chave aqui é que, contanto que o diário seja coerente, os metadados que estão faltando no sistema de arquivos (por exemplo, porque ele foi perdido em um evento de perda de energia) são normalmente , evitando assim a corrupção do sistema de arquivos. Além disso, o uso de data=journal também deve garantir a consistência dos dados reais do sistema de arquivos porque, pelo que entendi, o processo de recuperação também grava blocos de dados que foram confirmados no diário como parte de seu mecanismo de repetição.

Portanto, embora o ext4 não libere os caches de disco no final de um checkpoint, algumas etapas devem ser tomadas para maximizar a capacidade de recuperação em caso de perda de energia:

1. O sistema de arquivos deve ser montado com data=journal , e não data=writeback ( data=ordered não está disponível ao usar um diário externo). Este deve ser óbvio: queremos uma cópia de todos os blocos de dados de entrada dentro do diário, já que esses são os que provavelmente serão perdidos em um evento de perda de energia. Isso não é caro em termos de desempenho, já que os dispositivos NVMe são muito rápidos.

2. O tamanho máximo do diário de 102400 blocos (400 MB ao usar blocos do sistema de arquivos 4K) deve ser usado, de modo a maximizar a quantidade de dados que podem ser recuperados em uma reprodução de diário. Isso não deve ser um problema, já que todos os dispositivos NVMe têm pelo menos vários gigabytes de tamanho.

3. Problemas podem ainda surgir caso um desligamento inesperado ocorra durante uma operação intensiva de gravação. Se as transações forem descartadas do dispositivo de diário mais rapidamente do que as unidades de dados podem liberar seus caches por conta própria, poderá ocorrer perda de dados irrecuperável ou corrupção do sistema de arquivos.

Portanto, a conclusão é que, em minha opinião, não é 100% seguro desativar as barreiras de escrita, embora algumas precauções possam ser implementadas (# 1 e # 2) para tornar essa configuração um pouco mais segura.

    

Answer 2

Outra maneira de colocar sua pergunta é: ao fazer um checkpoint, ou seja, ao gravar os dados no journal no sistema de arquivos, o ext4 libera o cache (dos discos rotativos, no seu caso) antes de marcar a transação. como preenchido e atualizando o periódico de acordo?

Se olharmos para o código-fonte de jbd2 (que é responsável por lidar com o journalling) em checkpoint.c , vemos que jbd2_log_do_checkpoint() chama no fim :

__flush_batch(journal, &batch_count);

que chama :

write_dirty_buffer(journal->j_chkpt_bhs[i], REQ_SYNC);

Portanto, parece que deve ser seguro.

Relacionados: no passado também foi proposto um patch para usar o WRITE_SYNC no posto de verificação: O motivo foi que escrever os buffers tinham prioridade muito baixa e causavam o preenchimento do diário enquanto aguardavam a conclusão da gravação

    

Answer 3

Se desativar as barreiras de gravação aumenta significativamente o desempenho, isso significa que você não deve desativar as barreiras de gravação e que seus dados estão em risco. Veja esta parte da FAQ XFS para explicações.