Восстановление файловой системы, связанной с битовым разрушением, с известным местоположением битового переворота

Битовая гниль вполне реальна: обнаружив один пример, я теперь сталкиваюсь с расследованием ошибок файловой системы HFS+ - предложения приветствуются.

Дорогие друзья, мне нужен совет о следующих шагах, поскольку я обнаружил разницу в один бит между двумя образами дисков HFS+ размером ~ 1,5 ТБ.

Несколько лет назад я решил, что мне действительно следует лучше следить за своими кучей старых устаревших данных (в основном для Mac). Я начал планировать настройку архива, размещенного в ZFS. По мере того как моя коллекция устаревших дисков росла, я хранил файлы, беспорядочно реплицированные на нескольких дисках (чтобы попытаться предотвратить сбой физического диска). Недавно я наконец добрался до настройки массива ZFS и сумел скопировать первые старые архивные данные.

Возможно, неразумно, из-за нетерпения восстановить немного свободного места, я начал удалять несколько очевидных дубликатов файлов, сравнивая размер/дату изменения и т. д. В любом случае, один из моих дублированных файлов был старым образом диска более ранней версии емкостью 1,5 ТБ и на прихоть, я решил проверить скорость массива ZFS и дважды проверить отсутствие повреждений в исходных файлах, суммируя md5 обе копии, размещенные на массиве, и сравнивая их друг с другом, прежде чем удалить одну из тех, что, как я предполагал, будут идентичными копиями. ...

Что ж, я был удивлен, когда два файла размером 1,5 ТБ с одинаковой длиной в байтах, датами изменения и т. д. имели разные хэши! Ой-ой..

Затем я выполнил побайтовое сравнение двух файлов (используя), и я обнаружил одну несовпадающую разницу в байтах с двумя восьмеричными представлениями (022 и 222). ... то есть разница в один бит между двумя образами файловой системы HFS+ объемом 1,5 ТБ.

Я проверил, что к образам дисков не прикреплена связанная контрольная сумма (которую сгенерирует DiskUtility под MacOS... потому что тогда это бы сказало, какой образ был «в порядке», и IO мог бы просто удалить неисправный файл...), но ни один из них не был обнаружен. имел контрольную сумму, созданную во время создания изображения.

Что теперь? Я хотел бы идентифицировать файл в образах файловой системы, который имеет спорный бит (в конце концов, это может быть неважный файл ... или старое «свободное пространство» ... но это также могут быть метаданные, не относящиеся к файлам; простая попытка прочитать файл, смонтировав образ только для чтения, может сказать мне, какой образ в порядке, а какой нет... но как мне сопоставить местоположение смещения байтов в образе диска с файлом в файловой системе?).

Любые предложения относительно лучших инструментов/способа найти, какой файл в этой файловой системе содержит определенное смещение байтов?или любой другой подход, который я пропустил? Возможно, это автоматизированный способ систематического сравнения каждого файла в части смонтированных образов HFS+? Я полагаю, что можно было бы написать что-то для рекурсии по обоим ... но если это не даст чистого результата, то я все еще в неведении ... и если бы я мог сопоставить конкретное местоположение байта с файлом, тогда это должно быть быстрее.. (и было бы интересно узнать).

Большое спасибо!

М.

0 ответов

Другие вопросы по тегам