Как идентифицировать и исправить файлы с поврежденными / недоступными дисковыми блоками

9

У меня в конце 2011 года Macbook Pro под управлением Mavericks 10.9.2. Его единственный жесткий диск - это диск на 750 ГБ, отформатированный в Bootcamp. Он все еще работает достаточно хорошо, но при выполнении прохода дефрагментации я обнаружил, что есть куча файлов, которые отказываются перемещаться дефрагментатором (iDefrag).

При доступе к файлам iDefrag сообщает об ошибке POSIX 5. Выбор одного случайного файла и попытка скопировать файл в другое место в оболочке также сообщает об ошибке, которая заставляет меня думать, что проблема реальна и с диском / FS. Вывод cp:

cp: unity_nophysx.nexe: Input/output error

Насколько мне известно, код ошибки 5 - «Отказано в доступе», но процесс дефрагментации выполняется от имени администратора, и запуск cp с использованием sudo для подозрительного файла не имеет значения.

Дисковая утилита, fsck и Apple Hardware Test утверждают, что с диском все в порядке. Об ошибках SMART не сообщалось, и хотя были некоторые ошибки разрешений, они не были с файлами, на которые жалуется iDefrag, и Дисковая утилита утверждает, что исправила их без жалоб.

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

Мой вопрос заключается в том, как мне пометить эти поврежденные файлы как должным образом поврежденные и исправить или очистить их , чтобы клон диска был успешным и не зависал на файлах / блоках, к которым он не может получить доступ. Дисковая утилита не видит проблемы, и я не знаю ни командной строки, ни сторонних инструментов, которые бы выполняли эту работу. Я не хочу списывать весь диск и начинать с нуля, так как диск кажется исправным, поэтому я ищу инструменты для ремонта / диагностики.

— MrCranky
источник

Я советую вам прочитать это довольно подробное подобное обсуждение на SuperUser: superuser.com/q/148227 .

— дан

Я тестировал, к сожалению, на здоровом диске :), volitans-software.com/smart_utility.php . Это выглядит как довольно простой и серьезный инструмент. Вы можете попробовать это и, в частности, проверить счетчик «перераспределенных секторов».

— дан

8

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

Сделайте полную резервную копию вашего диска с помощью Time Machineили Carbon Copy Cloner

Проверьте эту резервную копию.
Выполните следующую тяжелую и рискованную (в случае, если у вас есть плохие блоки вне структуры вашей файловой системы) команду (убедитесь, что {} указан в кавычках, чтобы имена файлов, содержащие пробелы, работали):
```
find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
```

Эта тяжелая findкоманда напечатает для любого простого файла его имя (то есть не для чтения, а только для своей записи в каталоге), а затем продолжит полное и быстрое чтение всех его блоков данных.

После hiting первого файла , содержащий дефектные блоки, это findзаставит ядро войти read errorна /var/log/system.log, и это будет либо замедлить или привести вашу систему к полной остановке. Это будет в основном зависеть от емкости жесткого диска для перемещения поврежденных блоков в его внутреннем пуле, предназначенном для этой обычной задачи исправления. Этот файл, содержащий плохие блоки, будет фамилией, напечатанной find.

Запишите это имя файла на листе бумаги! Допустим, это имя файла:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

В этот момент вы можете findбыстро убить , нажав ctrl+ C. Если убить его не удастся, просто разбейте свой Mac.

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

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

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

Если команда не прекратит работу, вы не сможете убить ее как обычно, ваши данные полностью потеряны, и вам придется снова потерпеть крах на вашем Mac.

В этом последнем случае вы должны рассмотреть вопрос о замене диска и работать с последними резервными копиями. Некоторые другие файлы могут также содержать поврежденные блоки и могут оставаться необнаруженными в течение длительного времени, пока вы их не читали.

Ядро не выдаст ошибку чтения на блоке, который вы никогда не читали.

— Дан
источник

Ага, это именно та хитрость, на которую я надеялся. Первый проход с помощью скрипта find / dd затрагивает все файлы / блоки на диске, и, конечно же, я нахожу кучу файлов, которые выдают «Ошибка ввода / вывода», и я могу просто вывести журнал команды в файл и затем grep, чтобы выяснить, какие файлы являются duff. Кажется, что команда dd сама по себе недостаточна для запуска какого-либо автоматического исправления (я даже не знал, что это сделала OS X), но, по крайней мере, она дает мне надежный способ идентификации файлов.

— MrCranky

С другой стороны, когда ОС пытается прочитать файлы с этими поврежденными блоками, она не падает и не зависает. Я вижу May 10 20:42:15 ICE kernel[0]: disk0s2: I/O error.всплывающее окно в журналах, но не знаю, какой файл вызвал его. Но тогда команда работает довольно счастливо.

— MrCranky

Ваше ядро не зависает с BBFH, потому что на вашем диске все еще достаточно блоков, доступных для его исправления. ddничего не исправляет, цель этой команды - скопировать данные и преобразовать их как можно быстрее. Диск все еще способен исправлять световые ошибки. Будьте бдительны, цена диска ничто не сравнится с вашей работой.

— Ден

Ммм, да, я предположил, что: dd - просто тупой инструмент, чтобы собрать все данные из одного файла и поместить их куда-нибудь еще (в нашем случае, в воздух). Что действительно важно, так это то, что каждый блок, связанный с файлом, читается. То, что я не получаю, это то, что вы ожидаете от OS X в этом случае. Ясно, что ядро не может прочитать эти плохие блоки, но вы думаете, что сам диск может и может исправить их? Если он не может получить данные из исходного плохого блока, как он собирается перенести их в другое место?

— MrCranky

Отличный вопрос. Диск автоматически выполнит повторные попытки чтения блоков. Каждый раз положение головы механически находится в другом положении. Если одна из этих попыток окажется успешной, данные копируются в один из блоков, доступных для восстановления поврежденных блоков. Плохой блок помечается как плохой и никогда больше не будет использоваться. С другой стороны, если все попытки повторяются, данные не сохраняются, и через очень долгое время диск помечает блок как плохой и выделяет новый пустой для видимого диска. Ядро сообщит о неисправимой ошибке диска.

— Ден

4

Перезагрузитесь в однопользовательском режиме, удерживая Command+ Sво время загрузки. Когда вы увидите приглашение (должно выглядеть root #или что-то похожее), введите fsck -fи нажмите Return. Это встроенный в Mac инструмент проверки целостности файловой системы, позволяющий находить и исправлять ошибки в файловой системе при запуске. Выполняйте эту команду до тех пор, пока вы не увидите **The volume [volume name] was modified.**или инструмент не выйдет из строя три раза подряд.

Если инструмент выходит из строя, это может указывать на более серьезную проблему (но я не могу сказать вам, что, не видя выходных данных инструмента). В любом случае, убедитесь, что вы сделали резервную копию всего, что можете, прежде чем запускать какой-либо дисковый инструмент. Когда вы закончите, введите rebootприглашение и нажмите Enter, чтобы (как вы уже догадались!) Перезагрузить компьютер.

Для получения дополнительной информации вы можете найти страницы справочника fsck здесь .

— Matt
источник

Интересно, но похоже, что fsck, даже с -f и в однопользовательском режиме, делает то же, что и Дисковая утилита. Как и Дисковая утилита, она ничего не находит и думает, что с диском все в порядке. Я предполагаю, что он сканирует записи файловой системы, но я думаю, что моя проблема на уровне блоков - то есть файловая система хорошо структурирована, но реальные данные в файлах недоступны, когда дело доходит до чтения / копирование / дефрагментация их.

— MrCranky

1

→ MrCranky: правильно! fsck& Disk Utilityпроверяют целостность структуры файловой системы. Они читают дисковые блоки, выделенные структуре файловой системы. Они не предназначены для проверки целостности блоков данных. Следовательно, они могут работать на диске с ошибочными блоками без возникновения ошибок чтения. Если вы хотите проверить свой диск, даже блоки, которые могут быть неисправны, но на самом деле не используются, просто используйте базовый инструмент, как dd if=/dev/disk0 of=/dev/null ibs=1kи во время другого запуска оболочки tail -f /var/log/system.log. Это бесплатно, экстремально и не скрывает никаких ошибок.

— Ден

2

Я настоятельно рекомендую DiskWarrior для восстановления каталогов дисков и для сканирования потенциально поврежденных файлов .

Во время перестройки каталога он также может сообщить вам, если возникла задержка из-за сбоя диска.

— Адам
источник

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

— MrCranky

-1 Не просто ответ, а смесь комментариев и ответов.

— bot47

2

Отработав ответ Buscar, вы можете сделать это автоматически, используя довольно тяжелую командную строку foo.

sudo find / -type f -print0  | xargs -0 -I{} dd if='{}' of=/dev/null bs=1m 2>&1 | grep 'error' >>badfiles.txt  &

sudo: режим администратора
find -print0: абсолютный путь
xargs -0 -I {}: подставить {} в следующую команду
dd 2> & 1: перенаправить ошибку std на стандартный вывод
труба stdout в grep ищет ошибку строки
Добавьте результаты в файл списка ( примечание : это должно быть на внешнем носителе, если вы считаете, что ваш внутренний диск ненадежен)

— awiebe
источник

1

Как вы говорите, даже не ясно, повреждены ли эти файлы, по крайней мере, ваш Mac так не считает.

Каждая ОС создает неподвижные файлы, которые необходимы для ее работы (точки восстановления, в настоящее время активные файлы и т. Д.). Некоторые дефрагменты покажут их, некоторые нет.

Тот факт, что вы не можете получить к ним доступ или переместить их, не означает, что они повреждены.

Обычно Mac очень хорошо заботятся о себе.

Использование Apple для обслуживания: откройте Терминал и введите:

sudo periodic daily weekly monthly

затем Return, введите свой пароль администратора, и OS X позаботится о вас.

Посмотрите в Консоли отчеты о тех, кто вас интересует.

Находясь в консоли, ищите (ищите) любые ошибки ввода-вывода, которые указывали бы, что на вашем диске начинаются проблемы, чтобы дополнить Дисковую утилиту и выводы fsck.

Иногда я использую бесплатный инструмент под названием OnyX для дополнительного обслуживания. Это сделано по-французски, и, как они едят, это просто здорово :)

_{OnyX - это многофункциональная утилита для OS X, которая позволяет проверять загрузочный диск и структуру его системных файлов, запускать различные задачи обслуживания системы, настраивать некоторые скрытые параметры Finder, Dock, QuickTime, Safari, Mail, iTunes. окно входа в систему, Spotlight и многие приложения Apple для удаления кэшей, удаления определенного количества файлов и папок, которые могут стать громоздкими, и многое другое.}

Учитывая все вышесказанное, я не ставлю под сомнение ваше решение об использовании средства дефрагментации (iDefrag), поскольку я его не знаю, а скорее предлагаю альтернативные решения.

— Ruskes
источник

Использование дефрагментатора не является проблемой, я прекрасно знаю, что делает и не делает OS X в этом отношении. Эти файлы определенно не использовались, это были файлы данных для приложения, которое не было активным, и действительно приложение теперь нельзя перемещать.

— MrCranky

На Onyx - он снова делает немного больше, чем Disk Utility - проверяет SMART-статус диска, а затем запускает диагностику в стиле fsck (которая, как мы установили, считает, что в этом нет ничего плохого)

— MrCranky

Просто чтобы быть понятным, для любого, кто читает этот ответ, файлы наиболее определенно были повреждены, и Mac знал это, потому что мне не разрешали читать с них (копировать их, что угодно). Это было не потому, что они были системными файлами или использовались в то время, это было верно даже для файлов пользовательских данных. Периодическое обслуживание не помогло с проблемой, опять же, потому что похоже, что fsckона заботится только о проблемах файловой системы, а не блокирует проблемы доступности. Консоль показала ошибки только тогда, когда я вручную пытался скопировать / прочитать данные из одного из этих поврежденных файлов, и это не помогло их найти.

— MrCranky

0

Как бы неразумно это ни звучало, прежде чем что-либо делать, вы должны скопировать все свои данные на заведомо исправный диск. Если загрузка из установщика и копирование данных не удалась, есть утилита командной строки под названием 'dd', которая может выполнять низкоуровневое дублирование и гораздо более бескомпромиссным способом.

 man dd

для получения дополнительной информации о dd, включая использование и правильный синтаксис.

Еще один голос за пост Мэтта, загрузку однопользовательского режима и запуск

 fsck -fy

снова и снова, пока fsck не прекратит сообщать об ошибках.

DiskWarrior - голос за пост Адама. Это простое в использовании, но очень мощное приложение, которое будет сообщать о сбоях жесткого диска, проверять отдельные файлы на наличие ошибок и, если возможно, исправлять их, а также перестраивать и оптимизировать структуры каталогов.

Другое возможное решение, которое может показаться необоснованным, но часто является последней попыткой восстановить данные с большим количеством ежегодных доказательств успеха, - это вытащить диск, защитить его от влаги, используя несколько слоев морозильных пакетов, и поместить его в морозильник для 30-45 минут. Затем, пока диск холодный, установите диск во внешнюю док-станцию USB и используйте другую временную систему, чтобы снова попытаться скопировать поврежденные данные на другой диск. Как правило, это используется, если есть проблемы с оборудованием, и диск выходит из строя. Если вы можете скопировать весь диск с неповрежденными данными, это идеально, так как часто перераспределение и переформатирование дают накопителю новый срок службы.

— Chillin
источник

Как я уже сказал, fsck не сообщает об ошибках. Диск еще не является темпераментным или не сообщает о случайных ошибках, и список поврежденных файлов, по-видимому, не увеличивается, поэтому я не верю, что я пока что нахожусь на стадии «заморозить для последнего аварийного извлечения». Я также уже очень хорошо зарезервировал на уровне файлов / папок и не беспокоюсь о потере данных, как я сказал в вопросе. Приятно слышать еще один голос за DiskWarrior, хотя.

— MrCranky

@MrCranky: я полагаю, что вы ссылаетесь на что-то, опубликованное до обновления вашего вопроса; Я подкреплял идею fsck для тех, кто находит эту страницу в поисках решения схожих симптомов. Что касается всего, что я написал о сбое жесткого диска, никогда не повредит быть всеобъемлющим, опять же, для других и не обязательно для вас лично. Я видел свою справедливую долю отказов жесткого диска. Часто нет никаких признаков сбоя, даже с технологией SMART, пока вы больше не можете получить доступ к данным любым способом. Если вы заботитесь о данных, я настоятельно рекомендую вам приобрести новый диск и сделать резервную копию ваших данных.

— Chillin

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

— MrCranky

0

Для одного файла, который не может быть прочитан полностью из-за ошибки чтения с диска, вы можете использовать ddутилиту для дублирования файла на внешний том, заменяя NUL-байты для блоков, которые не могут быть прочитаны. Настоятельно рекомендуется выполнить копирование на другой том (например, «USB-диск» в приведенном ниже примере).

Пример:

dd if=/path/to/damaged/file of=/Volumes/USB\ Disk/file bs=512 conv=noerror,sync

Используя 512-байтовые блоки, будет восстановлено максимальное количество читаемых блоков.

Восстановление может занять много времени, так как ядро будет блокироваться на некоторое время при каждом неудачном чтении.

— Бяшка
источник