Ir para o conteúdo principal
Voltar aos artigos

ext4 data=journal: uma depreciação pede teste de recuperação

A retirada planejada de data=journal no ext4 pede inventário e ensaio de durabilidade. O modo não foi removido e o kernel citado ainda é candidato.

·3 min de leitura·2 visualizações

A nota da LWN sobre Linux 7.3-rc7 destaca a descontinuação do modo data=journal do ext4, com remoção prevista para o começo de 2028.[14] O modo continua presente nessa etapa; a mudança não retira o ext4 nem significa que a opção já deixou de funcionar.[14]

A leitura de engenharia é que uma depreciação de persistência pede mais que substituir um parâmetro. É necessário descobrir qual garantia a aplicação espera e demonstrar que a transição a preserva.

O que muda para quem desenvolve

No modo data=journal, os dados são gravados no journal antes de serem escritos no sistema de arquivos principal.[14] A documentação citada registra que esse modo desabilita delayed allocation e O_DIRECT.[14] A alteração consultada acrescenta o prazo de retirada, mas não oferece uma justificativa detalhada nem uma receita universal de migração.[14]

Minha recomendação é recuperar a intenção da configuração. Ela foi escolhida por uma necessidade conhecida, por uma recomendação antiga ou por herança de uma imagem? Essas situações pedem decisões diferentes. Trocar a opção sem responder à pergunta pode remover uma premissa que ninguém escreveu.

Separe a avaliação do sistema de arquivos da avaliação da aplicação. O aceite deveria dizer quais operações confirmadas precisam sobreviver a uma falha e qual estado é aceitável após a recuperação. “O volume montou” é uma verificação muito menor.

Como aplicar

Inventarie opções das montagens ativas, configurações persistentes e imagens usadas para criar novos hosts. Relacione cada ocorrência de data=journal à aplicação e à justificativa disponível. Não altere servidores durante esse levantamento.

Depois, prepare uma máquina virtual descartável com volume e dados sintéticos. Reproduza a sequência de escrita relevante para a aplicação, registre quais operações foram confirmadas e simule uma interrupção somente nesse ambiente isolado. Ao reiniciar, compare o estado recuperado com o contrato esperado.

Repita o ensaio para a configuração candidata, incluindo recuperação, latência e consumo de recursos. A comparação precisa conservar a carga e explicitar mudanças no restante do ambiente. Um resultado favorável em um teste curto não deve esconder uma regressão em outra condição de falha.

Antes da migração real, valide backup e restauração, defina critérios de interrupção e documente a reversão. Atualize também o processo que gera imagens, para não reintroduzir a opção antiga em instalações novas.

Cuidados e limites

Linux 7.3-rc7 é um candidato de lançamento para testes.[14] Linus Torvalds mantém a expectativa de versão final no fim de semana seguinte à nota, condicionada à ausência de novos problemas.[14] Isso não confirma disponibilidade da versão final nem recomenda instalar o candidato em produção.

A nota é breve e não apresenta uma lista de correções ou CVEs do candidato.[14] Não acrescente urgência de segurança que ela não demonstrou.

O prazo permite preparar uma transição com evidência. A prioridade é encontrar dependências e testar recuperação, não atualizar o kernel por impulso. Depreciação é um aviso para revisar um contrato operacional, não uma ordem para mudar tudo hoje.

Fonte

[14] Fonte: LWN.net, com complemento no commit oficial referenciado pela nota

Continue lendo

Windows 11 23H2: o inventário precisa saber a edição

O fim do suporte do 23H2 empresarial exige inventário por edição, piloto de compatibilidade e confirmação da atualização, não só máquinas ligadas.

·3 visualizações