FERRAMENTAS LINUX: Está parecendo que o problema de corrupção EXT4 no Linux 4.19 é causado pelo BLK-MQ

quarta-feira, 5 de dezembro de 2018

Está parecendo que o problema de corrupção EXT4 no Linux 4.19 é causado pelo BLK-MQ




Confira !!


A saga sobre a corrupção do sistema de arquivos EXT4 nos kernels do Linux 4.19 que aumentou nas últimas semanas pode estar chegando ao fim ... Este bug de corrupção de dados parece não ter origem no código EXT4.

Embora ainda não esteja 100% resolvido, parece que os problemas de corrupção do EXT4 no Linux 4.19 são realmente devidos a um problema dentro do código de bloco de várias filas "blk-mq" para esta série estável atual. Também parece que outros sistemas de arquivos podem ser afetados, apenas que o EXT4 é o sistema de arquivos mais comum e, portanto, a maioria dos relatórios. Essa é a crença mais recente para aqueles ansiosos por detalhes que não acompanham esse problema de perto.

Vários usuários - incluindo desenvolvedores de kernel do Linux upstream - descobriram que a estabilidade de seus dados é aprimorada após a desativação do código do MQ. Existem também algumas correções experimentais para resolver o problema depois que a bissectação finalmente transformou os prováveis ​​commits problemáticos. Foi uma tarefa árdua para os envolvidos simplesmente dividir o código do kernel devido ao comportamento desagradável, às vezes levando vários minutos ou mais antes que o problema de corrupção de dados se exibisse, eo problema nem sequer se originava do código EXT4.

O código de E / S do bloco multi-queue para o kernel Linux permite um potencial de desempenho / dimensionamento muito melhor nos modernos processadores multi-core atuais com armazenamento rápido. O BLK-MQ permite manipular várias filas distribuídas pelos encadeamentos da CPU, que podem ser mapeados para o número de filas de hardware disponíveis para um dispositivo de armazenamento. Com o tempo, mais pilotos têm suportado o BLK-MQ, enquanto os principais drivers, como o NVMe, o suportam há algum tempo.

ais código foi migrando para o MQ e os poucos recursos ausentes foram sendo endereçados . Para kernels com o modo blk-mq não habilitado por padrão, ele pode ser ativado no momento da inicialização com scsi_mod.use_blk_mq = 1 . Verificar se uma unidade está usando o código de E / S de várias filas pode ser feito verificando a presença do diretório / sys / block / DEVICE / mq .

Pelo menos por enquanto, baseado no bissecto do usuário, ele se parece com o blk-mq: falha a solicitação em caso de falha e blk-mq: problema diretamente se a fila hw não estiver ocupada em caso de 'nenhum' são os commits responsáveis ​​por fazer o sistema propenso ao problema de corrupção de dados no Linux 4.20+.

O mantenedor do subsistema de bloco Linux, Jens Axboe, do Facebook, publicou uma linha de correção de código que parece resolver esse problema. Ou a outra opção seria não usar o blk-mq até que a regressão seja resolvida. Pelo menos com o ritmo acelerado, particularmente nos últimos dias, com mais pessoas atingindo esse problema, parece que o bug logo será resolvido de uma vez por todas.


Fonte

Até a próxima  !!


Nenhum comentário:

Postar um comentário