Я пытаюсь отследить проблему повреждения данных, которая возникает при чтении в Win7x64, и у меня нет идей, что делать дальше.
Первоначально это проявилось при переносе ~ 2 ТБ данных на новый домашний NAS; когда я проверял копию, небольшой процент файлов был поврежден. Это было еще в декабре, и с тех пор я преследую эту проблему.
Каждое "искажение" - это один бит, переключаемый с 0 на 1 или с 1 на 0, в одном или нескольких местах в затронутых файлах. Когда в одном "запуске" затрагиваются несколько файлов, направление переворота в каждом случае одинаково.
Это не похоже на проблему с ОЗУ; моя система не поддерживает ECC RAM, но я выполнил несколько тестов памяти без ошибок. Система также работает неделями подряд без перезагрузки или каких-либо неожиданных сбоев (предостережение, потому что я ожидаю периодического сбоя Firefox), но я намеренно избегаю всего, что связано с перемещением больших объемов данных, пока я не смогу решить эту проблему. Нет CD рипы, видео транскодов и т.д.
В каждом отдельном случае, который я видел, перевернутый бит - это младший бит в седьмом байте шестнадцатибайтового блока данных. В большинстве, если не во всех случаях, которые я видел, байт с перевернутым битовым блоком имеет смещение… 2x7 или… 5X7. Я только начал очень усердно следить за проблемой на этом уровне примерно через месяц или около того.
Вот несколько первых примеров видеофайла с несколькими гигабайтами, который имел 121 бит-флип:
vv
000A46B2D0 1: d2 04 29 dc d9 bf 15 01 f9 34 50 b6 08 11 63 d4
2: d2 04 29 dc d9 bf 15 00 f9 34 50 b6 08 11 63 d4
000EC6B2D0 1: 32 51 26 4f ae a0 42 29 93 5d 64 43 a6 e2 ee ba
2: 32 51 26 4f ae a0 42 28 93 5d 64 43 a6 e2 ee ba
000F46B2D0 1: e8 67 bd 18 08 00 62 59 21 37 94 00 d0 34 67 cf
2: e8 67 bd 18 08 00 62 58 21 37 94 00 d0 34 67 cf
0018C6B2D0 1: b3 6e 0b 97 4e 7d 77 ab f9 74 38 6a 30 ee 9c 44
2: b3 6e 0b 97 4e 7d 77 aa f9 74 38 6a 30 ee 9c 44
001F46B2D0 1: 7e 87 0a c3 17 50 7c 55 39 b9 95 20 b8 6d 75 1a
2: 7e 87 0a c3 17 50 7c 54 39 b9 95 20 b8 6d 75 1a
^^
Десятизначное шестнадцатеричное значение слева - это позиция байта в двух сравниваемых файлах, а шестнадцать шестнадцатеричных пар - это шестнадцать байтов в файле, начиная с этой позиции. Обратите внимание на разницу значений в восьмом байте каждого столбца шестнадцатеричной пары. Корреляция происходит и на более высоком уровне; обратите внимание на тот факт, что первый байт каждой 16-байтовой строки имеет смещение, оканчивающееся на 46B2D0 или C6B2D0. Это было верно для всех 121 ошибок в этом конкретном файле.
Хотя эта проблема впервые проявляется при копировании больших файлов, я не думаю, что это проблема "копирования" как таковая, а скорее что-то происходит, когда файл читается, потому что на самом деле мне не нужно записывать данные обратно, чтобы увидеть проблему:
- При сравнении двух идентично-идентичных наборов файлов первый проход проверки выдаст ошибки, но при повторной проверке конкретных файлов, в которых обнаружены проблемы, они будут проверяться на идентичность.
- В одном случае у меня было сравнение, в котором произошел переворот в файле SOURCE для пары с известным идентичным идентификатором, и перечитал один и тот же файл несколько раз с помощью различных инструментов (Beyond Compare, md5sum, мой собственный скрипт сравнения файлов на уровне байтов). что дало вывод выше) дало тот же результат, но после перезагрузки файлы снова сравнивались как идентичные. Исходя из этого, я предполагаю, что все повторные чтения извлекали одинаковые неверные данные из кэша.
Также, похоже, что он не привязан к конкретному носителю данных или к тому, какое приложение я использую для копирования файлов или сравнения их впоследствии:
- Я видел поведение копий файлов и сравнений «только для чтения» с участием потребительского NAS, резервного USB-накопителя и двух разных внутренних дисков с вращающимися дисками во всех возможных комбинациях и направлениях. (Все файловые системы NTFS.)
- Я видел поведение при проверке копий, сделанных с помощью перетаскивания в Windows Explorer, Robocopy, Beyond Compare и Teracopy (последняя из которых сообщила о несоответствии контрольной суммы на этапе проверки), используя инструменты сравнения, включающие Beyond Compare (Hex View).), мой собственный скрипт сравнения на уровне байтов и сравнения с ранее сгенерированными значениями md5sum.
Я пытался определить, связано ли это с наличием какого-либо конкретного процесса в системе, но учитывая, сколько времени занимает каждый проход сравнения и насколько редкой была ошибка, это было трудно. Сказав это, был по крайней мере один проход, когда я получал много ошибок сравнения, и я убил процесс, который потреблял много памяти (служба резервного копирования CrashPlan, которая является безумным ресурсом), после чего остальная часть Проход сравнения прошел без ошибок. Я могу воспроизвести проблему, работает ли этот конкретный сервис, хотя.
(С этой точки зрения в этом вопросе дела обстоят немного сложнее, поскольку я не очень хорошо разбираюсь в земле).
Поскольку это выглядело так, как будто это может быть связано с файловым кешем Windows, я проверил потребление с помощью Sysinternals CacheSet. Типичные значения, когда я вижу проблему: текущий размер кэша ~ 1 ГБ и максимальный размер кэша 1,5-1,7 ГБ. Это кажется разумным для системы 8 ГБ; Я запускаю много жадных до оперативной памяти процессов, но система никогда не испытывает особых ограничений памяти. Диапазон рабочего набора отображается как 1 МБ - 1 ТБ (!!), что, безусловно, НЕ обоснованно. (Я также использовал CacheSet, чтобы экспериментально установить максимальный размер рабочего набора в 1 Гб, но этот параметр не пережил перезагрузку - не уверен, ожидается ли это или нет.)
В течение упомянутого выше периода, когда в кэше находилось явно плохое чтение, я также использовал CacheSet для очистки рабочего набора кэша, но последующее чтение "плохого" файла все еще показывало проблему до перезагрузки.
Размер рабочего набора во время плохого чтения, кажется, не имеет значения. Хотя я только начал проверять это недавно, Sysinternals RamMap показал значения Metafile Active/Total как 200MB/250MB на момент появления, что намного ниже максимума.
Это может быть таким же поведение видело в этом вопросе, предполагая , что Windows , показывает текущую дату поврежденной даты XMP поля.
Я думаю, что это охватывает все, что я знаю о проблеме до сих пор.