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.
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