Однобитовая ошибка на устройстве RAID?

Question

Впервые с тех пор, как у меня был компьютер (30 лет), я столкнулся с необнаруженной ошибкой однобитового диска. В массиве RAID. Последовательность событий была

1. Загрузите коллекцию цифровых изображений (файлы Camera Raw) с CF-карты.
2. Сделайте некоторое редактирование в Lightroom (который не обновляет оригинальный файл)
3. Резервное копирование всего на внешний архивный диск (используя Retrospect)
   ... проходит время (около 1 недели) ...
4. Снова откройте файл в Lightroom - он поврежден (большое квадратное пурпурное пятно)
5. Восстановите копию с архивного диска - восстановленная копия НЕ повреждена
6. Сравните два файла. Разница только в одном бите ... байт, который был первоначально 0x34, теперь 0xB4

Сетевое устройство представляет собой пару дисков по 2 ТБ в RAID-1 на аппаратной карте RAID (3WARE 9560SE-4LPML).

Учитывая вышеприведенную последовательность, ошибка была явно введена через некоторое время после шага 3, поскольку архивная копия не была повреждена, поэтому она не могла возникнуть во время первоначальной записи. Этот файл является необработанным файлом Canon CR2, и Lightroom никогда не обновляет оригинальные файлы RAW, они считаются "цифровыми негативами" и никогда не обновляются. Вместо этого он сохраняет все правки в виде файлов XMP боковой панели, содержащих последовательность примененных правок. Дата / время файла не изменяются с оригинала.

Ясно, что битовая ошибка произошла и была распространена аппаратным обеспечением RAID без предупреждения. Я проверил журналы ошибок RAID, и за последние 18 месяцев нет ничего примечательного (с момента последнего обновления программного обеспечения и прошивки).

Подвести итоги:

1. Данные изначально были написаны правильно
2. Затем он был прочитан правильно, когда он был скопирован в резервную копию.
3. Через некоторое время бит перевернулся на диске (поскольку файл ничего не переписывал).
4. Аппаратное обеспечение RAID настроено на запуск "проверки" один раз в неделю. Он не обнаружил ошибку.

Это просто причудливо. Я ожидаю ошибку несоответствия в журналах оборудования RAID.

Также я могу исключить неисправный диск, так как данные SMART на обоих дисках показывают ноль для всех применимых атрибутов ошибок:

196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

а все остальное тоже номинально.

У кого-нибудь есть сценарий, при котором это может произойти незамеченным?

Answer 1

Проверьте свой баран. Файловые системы, такие как zfs, рекомендуют ecc memory (проверку ошибок и исправление памяти) для предотвращения подобных проблем.

Ваш рейд-контролер просто записал информацию, которую ему дали, и предположил, что получил правильную информацию. Он не проверяет, что информация, которую он получает, верна, просто она написана правильно.

Ваша материнская плата может не поддерживать ecc-память, но это должно исправить эту проблему. Также возможно, что именно солнечная вспышка изменила этот байт на вас, поскольку чем больше у вас баранов, тем больше вероятность возникновения аномалии.

Я нахожусь за городом в своей камере, но я могу привести источники в понедельник

Answer 2

Одной из возможностей является случайное переключение битов в ОЗУ или контроллере при считывании на шаге 4. Если при чтении данные были повреждены, вы увидите их на шаге 4, а если они все еще будут кэшированы, вы также увидите их на шаге 6 при сравнении файлов, поскольку поврежденные кэшированные данные могут все еще использоваться.

Чтобы проверить этот случай, выключите и снова включите все ваше оборудование, чтобы убедиться, что кэши очищены, и попробуйте снова открыть файл (и выполнить сравнение с резервной копией). Если все хорошо, то это была проблема (нет способа узнать, на каком этапе чтения произошел переворот, так что вам просто придется списать это на счет как неразгаданную загадку).^†

Если это не удастся, вторая, еще более неудачная возможность - это, возможно, случайное переключение битов ОЗУ (или, скорее, на контроллере RAID, на основе вашего описания) при записи на шаге 1; но вы работали с хорошей кэшированной копией в шагах 2 и 3, несмотря на наличие поврежденной копии на диске. Неделю спустя, когда вы снова получили доступ к данным, вы, конечно, перечитали их с диска и получили поврежденные данные, которые были записаны изначально. Это делает много предположений и полагается на немного неудачи. Если это так, вам просто нужно восстановить файл резервной копии и двигаться дальше.

Это единственные две вещи, о которых я могу думать, правда. Это не похоже на проблему с самими дисками. В любом случае, поскольку невозможно определить, где в аппаратном обеспечении произошла ошибка, я рекомендую выполнить диагностику с полной памятью, чтобы быть в безопасности, хотя более вероятной причиной были нежелательные электромагнитные помехи или космические лучи. Как отметил канадец Люк в своем ответе, ECC RAM, если ваша материнская плата поддерживает его, защитит от этого типа событий, по крайней мере, на стороне RAM. Это на самом деле не редкость.

---

^{† Этот случай оказался проблемой ОП, а не второй возможностью.}