☰

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

tag-icon • tag-icon linux memory cache
Cache de memória perdendo sincronização com o disco

(Servidor Ubuntu Linux, 64 bits) Eu estava solucionando um problema com um arquivo (~3,0 GB) que acabei de baixar, mas ele 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 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 que algo estava errado com ele. 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

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

Para corrigir o download, criei um torrent na máquina de origem e abri-o na máquina de destino. Cinco pedaços de 1 MB de aproximadamente 3,0 GB falharam na verificação de integridade. Usei o torrent para consertar esses pedaços de arquivo e como a integridade do arquivo está correta.

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

  1. testei a memória commemtest86+, todos, exceto o teste de desvanecimento de bits. Eu esperava ver algum módulo de memória com falha, mas não havia nada. Está tudo bem.
  2. O sistema de arquivos é Ext4, sobre LVM2, sobre uma matriz RAID5 de 3 discos. Ext4 é considerado estável e se os dados fossem inconsistentes entre os discos, o mdadm teria avisado. Mas não há nada nos logs. Os logs de erros SMART estão limpos, os discos são novos (têm menos de 30 dias de "horas de inicialização").
  3. Estou procurando informações sobre quaisquer bugs de perda de dados em meu kernel atual (2.6.35), mas não parece haver nada, pelo que olhei.

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

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

Atualizar:Confirmei que os arquivos estão sendo gravados corretamente no disco, as páginas estão sendo alteradas após serem lidas do disco, ainda na memória. Fiz muito mais memtests (deixei fazendo bit fade test 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 catque lê com O_DIRECT, ou seja, ignorando o cache da página)

Há um padrão claro: isso sempre acontece no segundo byte em um alinhamento de 16 bytes. Nesse byte, quase sempre o bit 4 (LSB) muda para um, mas houve um caso em que o bit 2 mudou para zero.

Responder1

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

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

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

Se você tiver certeza de que o arquivo não foi modificado, a RAM com defeito é a explicação mais provável. Os 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 defeituosa.

informação relacionada