Por quanto tempo as gravações do sistema de arquivos podem ser armazenadas em cache com o ext4?

Há algum tempo, houve uma discussão sobre o ext4 potencialmente deixando arquivos vazios após uma desmontagem impura, resumida muito bem neste artigo . Basicamente, devido à alocação atrasada, as gravações podem ser mantidas no cache de gravação por um tempo muito maior que o intervalo de confirmação padrão do diário ext (5 segundos).

Os problemas parecem ter sido corrigidos em um patch que força a alocação de blocos em determinadas situações, forçando os dados para o disco após, no máximo, 5 segundos por padrão.

Gostaria de saber o que acontece quando um aplicativo substitui partes existentes de um arquivo, sem truncar ou anexar o próprio arquivo. Isso também será forçado a disco dentro de 5 segundos?

Parece uma situação diferente da anexada a um arquivo: ao anexar, o tamanho do arquivo é alterado, que é uma alteração de metadados; portanto, uma confirmação de diário será necessária dentro de 5 segundos e, devido a dados = pedidos, os dados deverão ser gravados antes disso por questões de segurança (caso contrário, partes de arquivos excluídos de outros usuários poderão aparecer para o proprietário do anexo Arquivo).

Ao substituir apenas os dados do arquivo, não há motivo para que a gravação dos dados deva ocorrer antes da confirmação do diário de metadados, pois os dados antigos pertencem ao mesmo usuário que o novo. A gravação ocorre antes do commit, de qualquer maneira, ou pode demorar mais que o intervalo de commit do diário? Se sim, quanto tempo?

Atualização: Eu sei que tudo isso é irrelevante ao fazer a coisa certa, ou seja, usando fsync (). (Esse foi o principal motivo de toda a discussão sobre ext4 e perda de dados - o problema dizia respeito apenas a aplicativos que não são fsync () ou não nos momentos certos.) Não estou escrevendo meu próprio aplicativo, estou perguntando porque não sei se todos os meus aplicativos fazem a coisa certa e quero saber um prazo aproximado para essas gravações "perigosas". O motivo para perguntar é que meu driver gráfico causa pânico no kernel regularmente e quero saber se tenho que me preocupar com mais do que os últimos 5 segundos de gravação de dados.

Você pode definir o intervalo de confirmação como um valor personalizado que, acredito, pode ser tão alto quanto um número inteiro não assinado de 32 bits de segundos; cerca de 4 bilhões de segundos, ou 136 anos. Isso está disponível na commitopção de montagem, que você pode aplicar da seguinte maneira (este é apenas um exemplo; você também pode configurá-lo fstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

O intervalo de confirmação não se baseia em nenhum tipo de condição, como se os dados são anexados ou substituem os dados existentes ou o que for. A commitopção de montagem (cujo padrão é 5 segundos, se você não fornecer a opção de montagem) é equivalente a fazer algo assim em um shell bash:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

Não confunda data=orderede esse intervalo global de sincronização do sistema de arquivos ("intervalo de confirmação" é talvez um termo menos significativo para aqueles que entendem a funcionalidade do programa de linha de comando sync; nesse caso, pode ser melhor denominado "intervalo de sincronização"). data=orderedé sobre a ordem em que os dados e os metadados são atualizados (onde data=writebacké "menos seguro / mais rápido" e data=journal"mais seguro / mais lento"). commit=12345678é sobre a frequência com que o próprio driver do sistema de arquivos força uma sincronização COMPLETA de TODOS os dados / diário / metadados / qualquer que seja a mídia física. E você certamente pode defini-lo para 136 anos, se quiser, e montar data=writeback,nobhe programas que não chamam fsync()ou sync()terão páginas sujas na RAM por ...

Atualização: Com base no seu contexto em sua edição de perguntas, eu diria que você deve executar o sistema de arquivos com as opções de montagem data=journal,commit=1ou mesmo com a syncopção de montagem, até conseguir resolver os pânico do kernel do driver gráfico. Isso manterá a integridade máxima dos dados, mas ao custo do desempenho. Você vai querer fazer isso especialmente se estiver gravando frequentemente dados em disco que não pode perder, e isso é duplamente importante se você não "confiar" nos aplicativos que está usando para empregar fsync()adequadamente.

Fonte: aqui e experiência pessoal

Qualquer que seja a resposta para sua pergunta, isso não importa.

O comportamento exposto garantido do sistema de arquivos ext4 é que "os dados estarão no disco após uma chamada sync/ sucesso fsync". Portanto, se você tiver um aplicativo que faça essa pergunta, insira as chamadas de sincronização nos pontos críticos em que a integridade dos dados precisa ser garantida. Se você é um usuário preocupado com o mesmo problema, pode chamar o syncutilitário de linha de comando antes de executar qualquer comportamento perigoso que possa causar um desligamento imundo.