Que opção de montagem usar para o sistema de arquivos ext3 para minimizar a perda ou a corrupção de dados?

Question

Eu tenho uma configuração incorporada usando um initramfs para o sistema de arquivos raiz, mas usando uma partição ext3 personalizada montada em uma unidade IDE flash compacta. Como a integridade dos dados em face da perda de energia é o fator mais importante em toda a configuração, usei as seguintes opções para montar (abaixo está a entrada do meu arquivo /etc/fstab

<file system> <mount pt> <type> <options>                         <dump><pass>
/dev/sda2     /data      ext3   auto,exec,relatime,sync,barrier=1 0     2

Eu vim por essas opções de ler na internet. O que me preocupa é que o conteúdo de /proc/mounts forneça o seguinte:

/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0

Pelo que entendi ao ler é que eu quero usar a opção data=journal para minha montagem, pois isso oferece a melhor proteção contra corrupção de dados. No entanto, a partir da página man para opções específicas do ext3 para mount , diz seguindo sobre a opção de write-back:

Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal.
This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.

Estou muito confuso sobre isso - a página man parece sugerir que para a integridade do sistema de arquivos eu quero especificar a opção data=writeback para mount , mas a maioria das outras referências que eu encontrei (incluindo alguns livros publicados sobre Linux embutido) sugerem que eu deveria estar usando data=journal . Qual seria a melhor abordagem para eu usar? A velocidade de gravação não é um problema - a integridade dos dados é, no entanto.

    

Answer 1

Não se deixe enganar pelo fato de que somente writeback mencionions internal filesystem integrity .
Com ext3 , se você usa journal , ordered ou writeback , os metadados do sistema de arquivos são sempre journalled e isso significa integridade do sistema de arquivos interno.

Os modos de dados oferecem uma forma de controle sobre como os dados ordinários são gravados no sistema de arquivos.
No modo writeback , as alterações de metadados são registradas primeiro no diário e um bloco de confirmação é gravado. Depois que a revista for atualizada, os metadados e os dados gravados poderão prosseguir. data=writeback pode ser um grave risco à segurança: se o sistema falhar ao anexar a um arquivo, após o comprometimento dos metadados ( e blocos de dados adicionais alocados), mas antes de os dados terem sido gravados (blocos de dados sobrescritos com novos dados), depois da recuperação do diário esse arquivo pode conter blocos preenchidos com dados de arquivos excluídos anteriormente - de qualquer usuário ¹ .

Portanto, se a integridade dos dados for sua principal preocupação e a velocidade não for importante, data=journal é o caminho a seguir.

    

Answer 2

Como você já deve ter notado, o ponto principal é que você não pode evitar que o seu sistema de arquivos de todos os tipos de falhas.

O que você pode fazer:

1. No lado do software, você pode usar fdatawrites após cada operação importante (veja este post de 2003 do Theodore T'so, um dos principais desenvolvedores do kernel do Linux FS, ainda é verdade. Há também este sobre uma grande perda de dados escondida em versões mais antigas do ext4)
2. Reduza o intervalo de confirmação para 1 segundo ( commit = 1 ) (consulte este artigo do LWN , é sobre ext4 mas contém informações realmente úteis sobre ext3). NB: Não deve ser necessário, com sync .
3. Como o RHEL apontou pelo sim, use * data_err = abort * e data = ordered
4. noatime reduzirá operações inúteis no sistema de arquivos
5. Como você já notou, barrier = 1 é uma boa maneira de minimizar a perda de dados (veja este post )
6. E sync também é, obviamente, uma das opções "Não quero perder meus dados".

No final, as opções de montagem paranoica podem ter esta aparência:

auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,

E você também pode garantir a integridade dos dados com um fsck automático em cada inicialização.

    

Answer 3

Tente alterar a parte da página de manual que você descreve:

writeback

Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.

Como don_crissti apontou, os outros modos não têm o "no entanto".