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

У меня есть Macbook Pro конца 2011 года, работающий под управлением 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, и Дисковая утилита утверждает, что исправила их без жалоб.

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

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

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

Ответы (7)

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

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

    Проверьте эту резервную копию.

  2. Выполните следующую тяжелую и рискованную (если у вас есть поврежденные блоки за пределами структуры вашей файловой системы) команду (убедитесь, что {} заключен в кавычки, чтобы имена файлов, содержащие пробелы, работали):

    find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
    

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

При попадании в первый файл, содержащий плохие блоки, это 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, чтобы узнать, какие файлы не работают. Кажется, что самой команды dd недостаточно, чтобы вызвать какое-либо автоматическое исправление (я даже не знал, что OS X делает это), но, по крайней мере, она дает мне надежный способ идентифицировать файлы.
Положительным моментом является то, что когда ОС пытается прочитать файлы с такими плохими блоками, она не падает и не зависает. Я вижу May 10 20:42:15 ICE kernel[0]: disk0s2: I/O error.всплывающее окно в журналах, но не знаю, какой файл вызвал его. Но затем команда работает вполне счастливо.
Ваше ядро ​​не зависает с BBFH, потому что на вашем диске все еще есть достаточно блоков, доступных в его пуле, чтобы исправить поврежденные блоки. ddничего не исправляет, эта команда предназначена для копирования данных и их преобразования как можно быстрее. Диск по-прежнему способен исправлять легкие ошибки. Будьте бдительны, цена диска ничто по сравнению с вашей работой.
Ммм, да, я так и предполагал: dd просто тупой инструмент для извлечения всех данных из одного файла и помещения их куда-то еще (в нашем случае, в воздух). Что действительно важно, так это то, что каждый блок, связанный с файлом, читается. Чего я не понимаю, так это того, что вы ожидаете от OS X в этом случае. Ясно, что ядро ​​не может прочитать эти плохие блоки, но как вы думаете, может ли сам диск их исправить? Если он не может получить данные из исходного плохого блока, как он собирается переместить их в другое место?
Отличный вопрос. Диск будет автоматически делать повторные попытки чтения блоков. Каждый раз положение головы механически меняется. Если одна из этих попыток успешна, данные копируются в один из блоков, доступных для восстановления плохих блоков. Плохой блок помечается как плохой и больше никогда не будет использоваться. С другой стороны, если все попытки будут неудачными, то данные не будут сохранены, и через очень долгое время диск пометит блок как плохой и выделит новый пустой на видимый диск. Ядро сообщит о неисправимой ошибке диска.
Учитывая то, что я вижу, все повторные попытки терпят неудачу, ядро ​​​​сообщает об ошибке ввода-вывода, но файл остается недоступным (предположительно, потому, что нет смысла помещать новый пустой блок на его место, потому что это повредит файл данные, и не оставлять никаких намеков на то, что произошло). Вы получите одну неисправимую ошибку диска, а затем каждый последующий доступ будет молча возвращать поврежденные данные. Но если он знает, что это произошло однажды, я не понимаю, почему OS X не сохраняет его в список файлов duff и не имеет инструмента обслуживания, который может сказать вам, что некоторые из них плохие, оставив это вам исправить!

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

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

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

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

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

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

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

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

sudo find / -type f -print0  | xargs -0 -I{} dd if='{}' of=/dev/null bs=1m 2>&1 | grep 'error' >>badfiles.txt  & 
  • судо: режим администратора
  • найти -print0: абсолютный путь
  • xargs -0 -I{} : заменить {} в следующей команде
  • dd 2>&1: перенаправить стандартную ошибку на стандартный вывод
  • канал stdout в grep ищет строковую ошибку
  • Добавьте результаты в файл списка ( примечание : это должно быть на внешнем носителе, если вы считаете, что ваш внутренний диск ненадежен)

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

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

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

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

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

sudo periodic daily weekly monthly 

затем нажмите «Возврат», введите пароль администратора, и OS X позаботится обо всем за вас.

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

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

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

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

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

Использование дефрагментатора не является проблемой, я прекрасно знаю, что делает и чего не делает OS X в этом отношении. Файлы точно не использовались, это были файлы данных для приложения, которое не было активным, да и приложение теперь нельзя переместить.
На Onyx — он снова делает немного больше, чем Disk Utility — проверяет состояние SMART диска, а затем запускает диагностику в стиле fsck (которая, как мы установили, считает, что в этом нет ничего плохого)
Просто для ясности: для всех, кто читает этот ответ, файлы определенно были повреждены, и Mac знал об этом, потому что мне не разрешалось их читать (копировать их, что угодно). Это было не потому, что они были системными файлами или использовались в то время, это было верно даже для файлов пользовательских данных. Периодическое обслуживание не помогло решить проблему, опять же потому, что, похоже fsck, оно заботится только о проблемах с файловой системой, а не о проблемах с доступностью. Консоль показывала ошибки только тогда, когда я пытался вручную скопировать/прочитать данные из одного из этих битых файлов, найти их не помогло.

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

 man dd

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


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

 fsck -fy 

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


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


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

Как я уже сказал, fsck не сообщает об ошибках. Диск еще не настроен и не сообщает о случайных ошибках, и список поврежденных файлов, похоже, не растет, поэтому я не думаю, что я еще близок к стадии «зависания для последней аварийной загрузки». Я также уже очень хорошо сделал резервную копию на уровне файлов / папок и не беспокоюсь о потере данных, как я сказал в вопросе. Приятно слышать еще один голос за DiskWarrior.
@MrCranky: я полагаю, вы ссылаетесь на что-то, опубликованное до того, как вы обновили свой вопрос; Я подкреплял идею fsck для всех, кто нашел эту страницу в поисках решения для подобных симптомов. Что касается всего, что я писал об отказе жесткого диска, никогда не помешает быть исчерпывающим, опять же, для других, а не обязательно для вас лично. Я видел свою долю отказов жестких дисков. Часто нет никаких признаков сбоя, даже с технологией SMART, до тех пор, пока вы больше не сможете получить доступ к данным каким-либо образом. Если вам небезразличны данные, я настоятельно рекомендую вам приобрести новый диск и сделать резервную копию ваших данных.
Я, конечно, не возражаю против рекомендации по резервному копированию, но дух формата вопросов и ответов заключается в том, чтобы ответить на поставленный вопрос, а не на общий вопрос «как починить сломанный диск» (которых много). Задолго до того, как я отредактировал его, чтобы добавить fsckв список «вещей, которые считают, что с диском все в порядке», я ответил на ответ, упомянув о fsckего полезности. fsckи Disk Utility выполняют почти одну и ту же функцию, а именно работают со структурами файловой системы, а не на уровне блоков. Я попытался уточнить, что это проблема блока, а не проблема файловой системы.

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

Пример:

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

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

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