Поиск сбойных блоков жёсткого диска и выбор между ремаппингом и заменой накопителя

Когда жёсткий диск начинает капризничать, файлы открываются с задержкой, а в системном журнале мелькают ошибки ввода-вывода, первое желание это понять масштаб беды. Сколько на накопителе нечитаемых участков, расползаются ли они дальше и есть ли смысл бороться или пора готовить замену. Ответы на эти вопросы даёт скромная утилита поиска сбойных блоков, которая методично прочёсывает поверхность накопителя и составляет список проблемных мест. Звучит как панацея, но на деле всё тоньше, и понимание этих тонкостей отделяет осмысленный ремонт от опасной самодеятельности.

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

Как утилита прочёсывает поверхность и что означают её ключи

Перед запуском полезно узнать размер блока файловой системы на исследуемом разделе, потому что от него зависит нумерация и корректность работы. Эти сведения выдаёт служебная утилита разбора файловой системы.

sudo dumpe2fs /dev/sdb1 | grep "Block size"

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

sudo badblocks -sv /dev/sdb

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

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

sudo badblocks -sv -o bad-sectors.txt /dev/sdb

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

Чем отличаются режимы проверки и почему запись бывает разрушительной

Помимо чтения у утилиты есть режимы с записью, и тут начинается зона повышенной опасности. Разрушающий режим записи заполняет каждый блок тестовыми образцами, проверяя, корректно ли они читаются обратно. Он выявляет дефекты надёжнее всего, но при этом стирает абсолютно все данные на накопителе, поэтому годится только для пустого диска, который не жалко.

sudo badblocks -wsv /dev/sdb

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

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

sudo badblocks -nsv /dev/sdb

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

Почему запускать проверку на смонтированном диске опасно

Утилита по умолчанию отказывается выполнять запись или неразрушающий тест на смонтированной файловой системе, и это защита, а не каприз. Любой пишущий режим на работающей файловой системе способен повредить её структуру и обрушить систему, даже если раздел смонтирован только для чтения. Существует ключ принудительного запуска, который снимает эту защиту, но прибегать к нему почти никогда не стоит: если кажется, что вы умнее защитного механизма, почти наверняка это не так.

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

После того как сбойные блоки найдены и сохранены в файл, их передают утилите проверки файловой системы, которая помечает участки негодными и исключает из использования. Этот приём называют горячей правкой, когда диск размонтируют, добавляют список битых блоков и монтируют обратно без полного цикла резервного копирования и восстановления.

sudo e2fsck -l bad-sectors.txt /dev/sdb1

Запускать проверку файловой системы на смонтированном разделе тоже небезопасно, поэтому раздел предварительно отключают. Утилита прочитает список и внесёт битые блоки в специальный служебный список файловой системы, после чего она перестанет на них что-либо писать.

Где проходит граница между ремаппингом и заменой диска

Здесь кроется самое важное недопонимание. Когда утилиты помечают блок негодным на уровне файловой системы, это вовсе не то же самое, что аппаратный ремаппинг внутри накопителя. Современный диск умеет сам переназначать дефектные секторы из скрытого резервного пула, и происходит это прозрачно, без участия операционной системы. Пометка же на уровне файловой системы лишь говорит программам не использовать определённые логические блоки, но физический дефект при этом никуда не девается, а резерв накопителя не трогается.

Тонкость в том, что аппаратный ремаппинг чаще всего срабатывает именно при записи в проблемный сектор. Когда накопитель пытается записать данные туда, где чтение давало сбой, он либо успешно пишет и снимает подозрение, либо переназначает сектор в резерв. Поэтому пишущая проверка нередко чистит часть сбоев, заставляя контроллер переназначить плохие секторы. Но это лечение работает, лишь пока в резервном пуле есть свободное место.

И вот ключевой сигнал к замене. Если накопитель не может переназначить сбойный сектор даже при записи, это почти наверняка значит, что резервный пул исчерпан и прятать дефекты больше негде. Такой диск уже не подлежит ремонту никакими утилитами, потому что проблема физическая, а запас прочности кончился. Когда же сбойные блоки появляются вновь после пометки и их число растёт от проверки к проверке, поверхность деградирует прогрессирующе, и борьба теряет смысл. Динамика тут важнее абсолютного числа: горстка стабильных дефектов на старом диске это одно, а лавинообразный рост это приговор.

Сколько длится проверка и как не загнать её в тупик

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

Хорошая новость в том, что долгий процесс можно прервать и продолжить позже. Если остановить утилиту сочетанием клавиш прерывания, в следующий раз её запускают с указанием блока, на котором всё оборвалось, и она не начинает с нуля. Это спасает, когда диск большой, а времени за один присест не хватает. Указание стартового блока избавляет от повторного прочёсывания уже проверенной части.

Стоит учитывать и расход памяти. Чем больше блоков утилита тестирует за один заход, тем быстрее идёт работа, но тем больше оперативной памяти она требует, причём в неразрушающем режиме потребность возрастает кратно. Если задать слишком крупную порцию, утилита почти сразу завершится с ошибкой нехватки памяти при выделении буферов. Слишком мелкая порция, наоборот, рискует пропустить дефекты, укрытые за внутренним буфером накопителя. Здесь нужен разумный баланс, и значение по умолчанию обычно его обеспечивает для большинства дисков.

Связь находок с встроенной самодиагностикой накопителя

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

Бывает и обратная ситуация, когда чисто читающая проверка не находит ничего, а самодиагностика уже тревожно сигналит ожидающими секторами. Это означает, что дефекты есть, но проявляются они только при определённых условиях, и тут как раз помогает пишущая проверка, которая провоцирует накопитель показать и переназначить скрытые проблемные участки. Совместное чтение результатов обоих инструментов даёт куда более достоверный диагноз, чем любой из них поодиночке.

Именно поэтому опытный подход к больному диску начинается с двух взглядов сразу: внешнего сканирования поверхности и внутренней телеметрии накопителя. Когда оба источника указывают в одну сторону, сомнений в диагнозе не остаётся, а решение о ремонте или замене опирается на факты с двух независимых сторон.

Чтобы не метаться между ремонтом и заменой, разумно опираться на простую логику оценки:

1. Найти сбойные блоки безопасным читающим режимом и оценить их количество;
2. Сопоставить результат с показаниями встроенной самодиагностики накопителя по переназначенным секторам;
3. Если диск пустой и его готовят к работе, прогнать пишущую проверку и дать контроллеру шанс переназначить дефекты;
4. Повторить проверку через время и сравнить, растёт ли число сбоев;
5. При растущем числе дефектов или невозможности их переназначить запланировать замену накопителя.

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

Что держать в голове

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

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