У меня 3 жестких диска, в следующих параграфах они названы /dev/sda, /dev/sdb и /dev/sdc, самый новый идет первым. Примечание: /dev/sdc имеет один основной раздел /dev/sdc1, один расширенный раздел /dev/sd2 и 3 логических раздела /dev/sdc5, /dev/sdc6 и /dev/sda7.
Я создал деградированное устройство RAID 5 /dev/md0 с /dev/sda5 и /dev/sdb5 (планировал добавить /dev/sdc5 к RAID, чтобы вернуть его в нормальное состояние), затем использовал /dev/md0 в качестве единственного физического тома LVM и создал логический том с файловой системой ext4 /dev/mapper/vg0-lv0.
К сожалению, при исследовании и игре с LVM, я запустился dd if=/dev/zero of=/dev/sdc1 bs=64M count=10после удаления /dev/sdc1. Так что на самом деле нули были записаны на /dev/sdc2, а сломанная часть таблицы разделов хранилась на /dev/sdc2 и в начальной части /dev/sdc5.
Когда я это понял, я сразу же сделал образ /dev/sdc через dd, вот так: dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img.
Несколько дней спустя у меня наконец появилось время попытаться восстановить данные на /dev/sdc, на самом деле только на /dev/sdc7, так как это единственный раздел без резервной копии. Я запустил testdisk с файлом образа sdc.img, использовал его функцию быстрого поиска, чтобы перестроить таблицу разделов, скопировал ее на /dev/loop0. /dev/loop0p7 (который является образом /dev/sdc7) вернулся и монтировался, и все файлы, похоже, в порядке. Затем я запустил find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sumсборку списка контрольных сумм MD5 для всех файлов на /dev/loop0p7.
При работе с физическим устройством /dev/sdc быстрый поиск testdisk не находит все разделы, глубокий поиск находит. Затем я построил список контрольных сумм MD5 sdc7.md5sum для всех файлов на физическом устройстве /dev/sdc7 с помощью аналогичной команды. Сравнив его с sdc7_image.md5sum, я обнаружил, что 4 файла отличаются. Сравнив их вручную, я заметил, что каждый файл имеет разницу всего в 1 байт. И поскольку один файл имеет CRC32 в своем имени, я могу подтвердить, что файл с физического устройства /dev/sdc7 правильный.
Итак, мой вопрос: почему произошла эта странная вещь? Я уже запустил, fsck.ext4 -c -c /dev/mapper/vg0-lv0чтобы убедиться, что там нет плохих блоков. Разница в 4 байта в данных объемом 1,2 ТБ — это такой небольшой процент, но это не дает мне уверенности в том, что в будущем стоит хранить данные на /dev/mapper/vg0-lv0.
Обновление: должен отметить, что все операции выполнялись в последней версии ArchLinux, запущенной в VirtualBox 4.1.16, которая работает в Windows 7. /dev/sda, /dev/sdb и /dev/sdc связаны с физическими жесткими дисками через VBoxManage internalcommands createrawvmdk. VirtualBox сообщил об ошибке VERR_ACCESS_DENIED только во время выполнения md5sums для физического /dev/sdc7, после отключения физического диска через diskpartWin7 никаких дальнейших ошибок не возникло.
решение1
Есть пара вещей, которые могли произойти. Во-первых, вы не упомянули размонтирование sdc7 перед созданием образа диска, так что, возможно, данные записывались в то время. Я предполагаю, что это не так, иначе вы бы не спрашивали. Я не могу винить вашу реакцию "первым делом создайте образ диска", это довольно хорошая реакция. Хотя я заметил, что до перезагрузки ядро все еще имело таблицу разделов в памяти, проверьте /proc/partitions.
Первое, что нужно проверить, это ошибки памяти. У вас может быть плохая оперативная память. Ваши данные, несомненно, прошли через оперативную память несколько раз. Я предполагаю, что у вас нет памяти ECC, которая, вероятно, выявит это.
Жесткие диски также имеют ошибки. Если посмотреть спецификации нескольких случайных потребительских жестких дисков, то там написано 1 на 100 Тбит. Вы скопировали 1,2 ТБ по крайней мере несколько раз (чтение из источника, чтение из места назначения), так что это что-то вроде 19 Тбит чтения. Наличие битовой ошибки в этом случае правдоподобно. (К сожалению, они не указывают частоту ошибок для записи в спецификациях).
Была ли какая-то закономерность или причина в однобайтовых повреждениях? cmp -lмогу ли я назвать байты, которые меняются. Например, если бы это было всегда одно и то же смещение на странице (размер вашей страницы, вероятно, 4 КБ) и всегда один и тот же бит, это бы почти однозначно указывало на неисправную оперативную память. Даже если бы это был только всегда один и тот же бит или одно и то же смещение, это было бы довольно убедительно (И у вас был CRC32 для всех четырех файлов или только для одного?)