[Resolvido] Atenção: cuidem as atualizações da sua distro (EXT4/kernel)

Marcos FRM disse:

Atualização III:

O bug torna-se ainda mais esotérico (usando a palavra de Ted Ts'o) porque quem o reportou, além da opção -l do mount, usa três opções de montagem não padrão e não recomendadas (nobarrier, journal_checksum e journal_async_commit). Pior: o bug acontece, caso durante a desmontagem (só aí) do sistema de arquivos, o sistema seja desligado incorretamente.

Nenhuma distribuiçao em sã consciência usa nenhuma dessas opções de montagem por padrão. Quem as usa é porque deve saber o que está fazendo (e saber se virar...).

Restringe ainda mais a abrangência. Ted Ts'o (Google) e Eric Sandeen (Red Hat) ainda não conseguiram reproduzi-lo consistentemente para um patch já ter sido cozido e enviado ao Linus. Nix (quem reportou o bug) diz que agora no fim de semana terá tempo para fazer todos os testes que Ted pediu. Se tudo der certo, semana que vem essa novela termina.

Marcos FRM disse:

Atualização III:

O bug torna-se ainda mais esotérico (usando a palavra de Ted Ts'o) porque quem o reportou, além da opção -l do mount, usa três opções de montagem não padrão e não recomendadas (nobarrier, journal_checksum e journal_async_commit). Pior: o bug acontece, caso durante a desmontagem (só aí) do sistema de arquivos, o sistema seja desligado incorretamente.

.

H4RD50FT.RSD disse:

Marcos, depois de ler esses reports eu estaria errado em achar que esse bug já vem de longa data (talvez desde da criação do EXT4) e só apareceu por causa de um uso bastante exótico do mount?

ignacho disse:

A título de curiosidade: para que cargas d'água servem essas opções e para que alguém a ativaria? Aliás, nem posso imaginar como o cara fez para ativá-las.

Marcos FRM disse:

Enquanto os desevolvedores não conseguirem diagnosticar, não é possível saber.


As opções são adicionadas no fstab.

nobarrier diz para o kernel não proteger operações que requeiram ordenameto entre flushes do write cache do dispositivo. Dá melhor desempenho pois o firmware pode buferizar/reordenar a vontade as operações de escrita. Essa opção não deve ser usada por pobres mortais, sob risco de grave corrompimento do sistema de arquivos no caso de desligamentos incorretos. No bug report, ela é usada com segurança pois Nix usa uma palca RAID (em RAID-5) por hardware da Areca com bateria de backup. Então, mesmo numa falta de energia, os dados que ficaram pendentes quando o sistema caiu são gravados nos discos no próximo boot pelo firmware da placa. A bateria presente nela serve para mantê-los salvos até o próximo boot.

journal_checksum é um recurso novo do EXT4 que apareceu no kernel 3.5 para proteger por checksums várias estruturas do sistema de arquivos (metadados) e não apenas o journal. Porém é um código novíssimo e com pouco teste. Não deve ser usado em produção.

journal_async_commit evita uma barreira entre a transação e o commit (do journal) do EXT4 no modo data=ordered. A ordenação é relaxada e a saúde do sistema de arquivos é mantida por causa do checksum do journal no caso de desligamentos incorretos. Tenho dúvidas ser essa opção tem efeito com nobarrier.

hugoleal85 disse:

Em resumo, continuem utilizando seus Kernels 3.4, 3.5 e 3.6 tranquilamente.

ignacho disse:

Saiu a correção do bug
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8c673cbc7682b3f2862fe42f8069cac20c09e160

Saíram hoje as versões 3.4.17 e 3.6.5. Não sei se é referente à essa correção.;



O único contra é que o 3.5 já está em EOL (distros que adotaram esta versão oficialmente vão ter que providenciar os backports de segurança por conta própria).

ice2642 disse:

chega a impressionar a velocidade como conseguem resolver e achar problemas em sistema de código aberto.

é aquela velho historia, a união faz a força.

[]'s