Há algum tempo, houve alguma discussão sobre o potencial do ext4 deixar arquivos vazios após uma desmontagem impura, resumindo muito bemneste artigo. Basicamente, devido à alocação atrasada, as gravações podem ser mantidas no cache de gravação por um tempo muito maior do 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 assim os dados para o disco após no máximo 5 segundos por padrão.
Estou me perguntando 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 para disco em 5 segundos?
Parece uma situação diferente de anexar a um arquivo: ao anexar, o tamanho do arquivo muda, o que é uma alteração de metadados; portanto, um commit do diário será necessário dentro de 5 segundos, e por causa de data=ordered, os dados terão que 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 arquivo anexado arquivo).
Ao substituir apenas os dados do arquivo, não há razão para que a gravação dos dados deva acontecer antes da confirmação do diário de metadados, pois os dados antigos pertencem ao mesmo usuário que o novo. Então, a gravação acontece antes do commit ou pode ser atrasada por mais tempo do que o intervalo de commit do diário? Se sim, quanto tempo?
Atualização: sei que tudo isso é irrelevante na hora de fazer a coisa certa, ou seja, usar 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 faziam fsync() ou não estavam nos momentos certos.) Não estou escrevendo meu próprio aplicativo, estou perguntando porque eu 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 da pergunta é que meu driver gráfico causa pânico no kernel regularmente e quero saber se preciso me preocupar com mais do que os últimos 5 segundos de gravação de dados.
Responder1
Você pode definir o intervalo de confirmação para um valor personalizado que, acredito, pode ser tão alto quanto um número inteiro não assinado de segundos de 32 bits; então, cerca de 4 bilhões de segundos, ou 136 anos. Isso está disponível através da commitopção mount, que você pode colocar em vigor da seguinte maneira (isto é 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 é baseado em nenhum tipo de condição, como se os dados são anexados ou substituídos por dados existentes ou qualquer outra coisa. A commitopção mount (cujo padrão é 5 segundos se você não fornecer a opção mount) é 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=orderedesse intervalo de sincronização global do sistema de arquivos ("intervalo de confirmação" talvez seja um termo menos significativo para aqueles de nós que entendem a funcionalidade do programa de linha de comando sync; nesse caso, pode ser melhor denominado "intervalo de sincronização"). data=orderedé sobre oordemem que 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ários/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,nobhprogramas que não chamam fsync()ou sync()que terão páginas sujas na RAM por... várias vidas.
Atualização: Com base no seu contexto na edição da sua pergunta, eu diria que você deve executar seu sistema de arquivos com opções de montagem data=journal,commit=1ou mesmo com a syncopção de montagem, até que seja capaz de resolver os pânicos do kernel do driver gráfico. Isso manterá a integridade máxima dos dados, mas às custas do desempenho. Você desejará 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: aquie experiência pessoal
Responder2
Qualquer que seja a resposta à sua pergunta, não importa.
Ogarantido expostoO comportamento do sistema de arquivos ext4 é que "os dados estarão no disco após uma chamada sync/ sucesso fsync". Portanto, se você possui uma aplicação que faz você fazer essa pergunta, você deve inserir chamadas de sincronização nos pontos críticos onde a integridade dos dados precisa ser garantida. Se você for um usuário preocupado com o mesmo problema, poderá chamar o syncutilitário de linha de comando antes de executar qualquer comportamento perigoso que possa causar um desligamento incorreto.