☰

Кэш-память теряет синхронизацию с диском

tag-icon • tag-icon linux memory cache
Кэш-память теряет синхронизацию с диском

(Сервер Ubuntu Linux, 64-бит) Я устранял неполадки с файлом (~3,0 ГБ), который я только что загрузил, но он не прошел тест на целостность, когда обнаружил нечто действительно необычное.

Во-первых, это MD5 файла после загрузки, который не совпал с ожидаемым значением:

~% md5sum media.iso 
5d74facb904cc1765a468354908a8f34  media.iso

Прошло некоторое время, за это время файл не должен был измениться, но когда я снова проверил файл:

~% md5sum media.iso
a5b97c5016afb39bd67ccfc3fa6ca59e  media.iso

Это было действительно неожиданно. Поскольку у меня много оперативной памяти, я подозревал, что это эффект кэширования и что-то с ним пошло не так. Я решил повторить попытку со всем файлом с диска, к моему удивлению:

~% 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

Я переделал его, и теперь он, кажется, остается постоянным, хотя это все еще не то значение, которое я ожидал. Конечно,содержимое кэш-памяти отличалось от содержимого на диске. Это большая проблема.

Чтобы исправить загрузку, я создал торрент на исходной машине и открыл его на целевой машине. Пять кусков по 1 МБ из ~3,0 ГБ не прошли проверку целостности. Я использовал торрент, чтобы исправить эти куски файлов, и как целостность файлов в порядке.

Теперь проблема состоит в том, чтобы определить, где данные рассинхронизировались.

  1. Я проверил память с помощьюmemtest86+, все, кроме теста на выцветание бита. Я ожидал увидеть какой-то неисправный модуль памяти, но ничего не было. Все в порядке.
  2. Файловая система — Ext4, поверх LVM2, поверх 3-дискового массива RAID5. Ext4 считается стабильной, и если бы данные между дисками были несогласованными, mdadm бы предупредил. Но в журналах ничего нет. Журналы ошибок SMART чистые, диски новые (имеют менее 30 дней «часов работы»).
  3. Я ищу информацию о каких-либо ошибках потери данных в моем текущем ядре (2.6.35), но, насколько я могу судить, ничего подобного не обнаружено.

Есть идеи, что еще я могу проверить или где именно может быть дефект/ошибка?

Это Ubuntu 10.10 64-бит, Core i7 930, 6 ГБ не-ECC RAM.

Обновлять:Я подтвердил, что файлы правильно записываются на диск, страницы изменяются после чтения с диска, пока они находятся в памяти. Я сделал еще много memtests (я оставил его делать bit fade test на ночь), и все еще ничего. Все модули памяти кажутся в порядке.

Еще несколько тестов:

~% 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это версия, catкоторая читает с помощью O_DIRECT, то есть, обходя кэш страниц)

Есть четкая закономерность: это всегда происходит со 2-м байтом в 16-байтовом выравнивании. В этом байте почти всегда бит 4 (LSB) переключается на единицу, но был один случай, когда бит 2 переключался на ноль.

решение1

Если md5sum файла изменяется, существует несколько возможных объяснений в порядке убывания вероятности:

  • Файл был записан в.
  • Неисправна оперативная память (или другой компонент материнской платы, но оперативная память — наиболее подверженный сбоям элемент).
  • Ваше хранилище неисправно. (Маловероятно, поскольку неисправное хранилище обычно приводит к нечитаемым файлам, а не к повреждению данных.)
  • Ошибка ядра, возможно, в коде файловой системы. (Маловероятно для ext4.)

Обратите внимание, что «несоответствие между диском и кэшем» — это симптом, а не причина. Это даже не симптом, который вы наблюдали: то, что вы наблюдали, было разницей между памятью в момент времени T и памятью в момент времени T'.

Если вы уверены, что файл не был изменен, то наиболее вероятным объяснением является неисправная оперативная память. Тесты памяти не всегда, к сожалению, обнаруживают неисправную оперативную память. Если вы можете получить две разные копии файла, сравните их ( cmp -l file1 file2); если различия выровнены (например, различия всегда находятся на 42-м бите 16-байтовой последовательности) или состоят из смещенных блоков (признак повреждения, произошедшего с переменной указателя), все признаки указывают на неисправную оперативную память.

Связанный контент