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

Question

Algum tempo atrás, tem havido alguma discussão sobre o ext4 potencialmente deixando arquivos vazios após uma desmontagem impura, resumindo bem neste artigo . Basicamente, devido à alocação atrasada, as gravações podem ser mantidas no cache de gravação por um tempo muito mais longo 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 certas situações, forçando os dados para o disco depois de no máximo 5 segundos por padrão.

Eu estou querendo saber o que acontece quando um aplicativo sobrescreve partes existentes de um arquivo, sem truncar ou anexar o arquivo em si. Isso será forçado para o disco dentro de 5 segundos também?

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

Ao sobrescrever dados de arquivo, não há motivo para que a gravação de dados tenha que acontecer antes do envio de metadados, já que os dados antigos pertencem ao mesmo usuário que o novo. Então, a gravação acontece antes do commit de qualquer maneira, ou pode ser atrasada por mais tempo do que o intervalo de confirmação do diário? Se sim, quanto tempo?

Atualização: Eu sei que tudo isso é irrelevante quando se está fazendo a coisa certa, isto é, usando o fsync (). (Esse foi o principal motivo de toda a discussão sobre ext4 e perda de dados - o problema só dizia respeito a aplicativos que não fsync () ou não nos momentos certos.) Eu 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". A razão para perguntar é que o meu driver gráfico causa pânicos no kernel regularmente, e eu quero saber se eu tenho que me preocupar com mais do que os últimos 5 segundos de gravação de dados.

    

Answer 1

Você pode definir o intervalo de confirmação para um valor personalizado que, acredito, pode ser tão alto quanto um número inteiro sem sinal de 32 bits de segundos; cerca de 4 bilhões de segundos, ou 136 anos. Isso está disponível através da opção commit mount, que você pode colocar em vigor da seguinte forma (isso é apenas um exemplo; você também pode definir isso em 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 sobrescrevem dados existentes ou o que quer que seja. A opção commit mount (cujo padrão é 5 segundos se você não fornecer a opção de montagem) é equivalente a fazer algo parecido com isto 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=ordered e este intervalo de sincronização do sistema de arquivos global ("intervalo de confirmação" é talvez um termo menos significativo para aqueles que entendem a funcionalidade do programa de linha de comando sync , caso em que pode ser melhor chamado o "intervalo de sincronização"). data=ordered é sobre a ordem na qual os dados e 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 / o que quer que seja para a mídia física. E você certamente pode configurá-lo para 136 anos se quiser, e montar com data=writeback,nobh e programas que não chamam fsync() ou sync() terão páginas sujas na RAM por ... várias vidas úteis.

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

Fonte: aqui e experiência pessoal

    

Answer 2

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

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