Cache de memória perdendo sincronização com disco

Question

(servidor Ubuntu Linux, 64 bits) Eu estava solucionando um problema com um arquivo (~ 3,0 GB) que acabei de baixar, mas estava falhando no teste de integridade, quando descobri algo realmente incomum.

Primeiro, este é o MD5 do arquivo após o download, que não corresponde ao valor esperado:

~% md5sum media.iso 
5d74facb904cc1765a468354908a8f34  media.iso

Algum tempo se passa, nada deveria ter mudado o arquivo durante esse tempo, mas quando fui verificar o arquivo novamente:

~% md5sum media.iso
a5b97c5016afb39bd67ccfc3fa6ca59e  media.iso

Isso foi realmente inesperado. Como tenho muita RAM, suspeitei que esse fosse o efeito do cache e algo estava errado com isso. Eu decidi tentar novamente com o arquivo inteiro do disco, para minha surpresa:

~% sudo sysctl -w vm.drop_caches=3    # This linux command invalidates
vm.drop_caches = 3                    # everything in the memory cache.
~% md5sum media.iso
2992aa6270f6e1de9154730ed3beedc1  media.iso

Eu o refiz e agora ele parece permanecer consistente, embora isso ainda não seja o valor que eu esperava. Certamente, o conteúdo no cache de memória era diferente do conteúdo no disco . Este é o grande problema.

Para corrigir o download, criei um torrent na máquina de origem e o abri na máquina de destino. Cinco pedaços de 1 MB de ~ 3,0 GB falharam na verificação de integridade. Eu usei o torrent para corrigir esses pedaços de arquivos e como a integridade do arquivo é ok.

O problema agora é determinar onde os dados ficaram fora de sincronia.

1. Eu testei a memória com memtest86 + , tudo menos o teste de desvanecimento de bits. Eu estava esperando ver algum módulo de memória com falha, mas não havia nada. Está tudo bem.
2. O sistema de arquivos é o Ext4, sobre o LVM2, em um array RAID5 de 3 discos. Ext4 é considerado estável, e se os dados forem inconsistentes entre os discos, o mdadm teria avisado. Mas não há nada nos logs. INTELIGENTE. logs de erros são limpos, os discos são novos (têm menos de 30 dias de "poder-em-horas").
3. Estou procurando informações sobre quaisquer erros de perda de dados no meu kernel atual (2.6.35), mas parece que não existe nada, até onde eu olhei.

Alguma idéia sobre o que mais eu poderia verificar, ou onde exatamente poderia estar o defeito / bug?

É uma RAM não ECC do Ubuntu 10.10 de 64 bits, Core i7 930, 6 GB.

Atualização: Confirmei que os arquivos estão sendo gravados corretamente no disco, as páginas estão sendo alteradas depois de serem lidas do disco, enquanto na memória. Fiz muito mais memtests (deixei o teste de fade bit durante a noite), e ainda nada. Todos os módulos de memória parecem ok.

Mais alguns testes:

~% md5sum media.iso 
cc8bcf1ce67ff7704eadc2222650c087  media.iso
~% cp media.iso tmp1
~% md5sum tmp1 
bde6c54b2d7b03404b43056b908036ed  tmp1
~% md5sum media.iso 
134f607cf4c633ef11d2576d1c635d08  media.iso    # ← THIS IS THE CORRECT VALUE
~% cmp -l media.iso tmp1
  98697009 101 121
~% udiff <(xxd -s ... media.iso) <(xxd -s ... tmp1 )
--- /proc/self/fd/11    2010-11-03 14:52:55.649433000 -0200
+++ /proc/self/fd/13    2010-11-03 14:52:55.649433000 -0200
@@ -13,7 +13,7 @@
 5e1fef1: 280f 5a87 37d2 e6d6 647d bebe f04e 64d8  (.Z.7...d}...Nd.
 5e1ff01: 19a5 2ff4 178b 1e37 afb0 e914 e03f bd62  ../....7.....?.b
 5e1ff11: 2b8d 4245 985f a9f8 a993 1f51 6d31 30e7  +.BE._.....Qm10.
-5e1ff21: 8274 0d35 ab8f 86b7 130f e1d7 20c6 3541  .t.5........ .5A
+5e1ff21: 8274 0d35 ab8f 86b7 130f e1d7 20c6 3551  .t.5........ .5Q
 5e1ff31: 387b f226 6348 fabc 1eae 67ef adda c3b6  8{.&cH....g.....
 5e1ff41: a931 bf29 690f 25f9 8922 6dcc 009f 60a5  .1.)i.%.."m...'.
 5e1ff51: 559a 9d03 92cb fb5c a75f a26e 0954 0af4  U......\._.n.T..

~% md5sum media.iso        
54d67cc4dcad49b6d1bf6619074b471c  media.iso
~% direcat media.iso|md5sum
134f607cf4c633ef11d2576d1c635d08  -
~% direcat media.iso | cmp -l media.iso -
  98697009 121 101
 231297649 146 147
 519630641 177 157
2291859249 377 357
2442055473 127 107
2907131697 171 151

( direcat é uma versão de cat que lê com O_DIRECT , ou seja, ignorando o cache de páginas)

Há um padrão claro: sempre acontece com o segundo byte em um alinhamento de 16 bytes. Nesse byte, quase sempre o bit 4 (LSB) vira para um, mas havia uma instância em que o bit 2 era invertido para zero.

    

Answer 1

Se o md5sum de um arquivo for alterado, existem várias explicações possíveis, em ordem de probabilidade:

• O arquivo foi gravado em.
• Sua RAM está com defeito (ou outro componente da placa-mãe, mas a RAM é de longe a mais propensa a falhas).
• Seu armazenamento está com defeito. (É improvável porque o armazenamento com defeito geralmente leva a um arquivo ilegível, não a dados corrompidos.)
• Um erro do kernel, talvez no código do sistema de arquivos. (Altamente improvável com ext4.)

Observe que “inconsistência entre o disco e o cache” é um sintoma, não uma causa. Não é sequer um sintoma que você observou: o que você observou foi uma diferença entre a memória no tempo T e a memória no tempo T '.

Se você tiver certeza de que o arquivo não estava sendo modificado, a RAM com defeito é a explicação mais provável. Testes de memória nem sempre detectam RAM ruim, infelizmente. Se você conseguir duas cópias diferentes do arquivo, compare-as ( cmp -l file1 file2 ); se as diferenças estiverem alinhadas (por exemplo, as diferenças estão sempre no 42º bit de uma sequência de 16 bytes) ou consistirem em blocos deslocados (o sinal de corrupção ocorrendo em uma variável de ponteiro), todos os sinais apontam para RAM com defeito.