тестирование внесения неисправности mdadm со сбойными блоками или другими неисправимыми ошибками
Я недавно потерял диск в своем RAID-массиве (и получил электронное письмо от системы, предупреждающей меня об этом, которое было ужасно хорошо), и после некоторой перестановки диска и загрузки нового диска, я все безопасен и надежен. Но по пути, я нашел этот поток, который получил меня к размышлению о том, как Вы могли на самом деле протестировать на ошибки диска и другие Плохие Вещи без них на самом деле появление. Когда я выполнил предложенную команду tar:
tar c /my/raid/device/mount/point > /dev/null
это завершилось за несколько секунд, который является ясно не достаточно долго, чтобы система на самом деле считала все файлы (хорошо более чем тебибайт) - таким образом, я предполагаю, что мой первый вопрос состоит в том, почему это, возможно, не работало. Если я делаю что-то вроде этого:
find . -type f | xargs md5sum
Та команда работает очень хорошо, и требуется много времени для завершения..., но это также загружает ЦП, делающий все подведение итогов. Этот мог бы или не мог бы быть быстрее или легче, чем "tar" - мне более любопытно относительно того, почему команда tar не работала, как я ожидал.
Так или иначе - второй вопрос, и в более общем плане: есть ли способ сделать что-то вдоль этих строк, чтобы сделать тестирование внесения неисправности:
- найдите (или создайте), файл, о котором я не забочусь...
- решите, что блок на диске используется, чтобы хранить этот конкретный файл...
- фальсифицируйте программное обеспечение/ОС в размышление, что этот блок "плох" (я принимаю путем маркировки его так или иначе, это - то, где мое знание заканчивается),
- выполните мои сценарии тестирования и/или стандартные программы проверки ошибок
- подтвердите, что массив оба отчета, ошибка и делает то, что другое корректирующее действие необходимо...
- отметьте тот блок/сектор как "хороший" снова, таким образом, система/ОС использует его в качестве нормального.
Это походит на что-то, что было бы выполнимо, но у меня нет достаточного детального знания инструментов Linux, которые позволили бы мне отмечать блок как плохой на уровне устройств без него на самом деле БЫТЬ сбойным блоком...
мысли об этом? Или, если существует намного более изящный способ решить это, я рад услышать это также...
На ваш первый вопрос:
tar c /my/raid/device/mount/point > /dev/null
Будет зависеть от того, как ведет себя tar вашего дистрибутива в отсутствие параметра "f". Я пробовал это в системе Debian (wheezy), и она вела себя так, как вы могли ожидать - архив был записан на стандартный вывод. Однако в системе FreeBSD. он возвращает ошибку:
tar: Failed to open '/dev/sa0'
Более универсальным подходом было бы явное указание stdout в качестве архива:
tar cf - /my/raid/device/mount/point > /dev/null
Edit: Doh! Или просто забудьте о перенаправлении:
tar cf /dev/null /my/raid/device/mount/point
В дополнение к отличному ответу Кассандри, я бы также рекомендовал использовать SMART, если ваши физические диски поддерживают его для прогнозирования сбоев.
В Linux есть много полезной инфраструктуры внедрения ошибок. Один из них может быть полезен для ваших усилий по тестированию.
Страница 7 этой презентации показывает пример имитации проблемы с блочным устройством с помощью dmsetup .
https://mbroz.fedorapeople.org/ говорит / DeviceMapperBasics / dm.pdf
md (4) сам имеет режим под названием FAULTY , который вы можете использовать для имитации ошибок чтения / записи.
Неисправный
Модуль FAULTY md предназначен для тестирования. Неисправный массив имеет ровно одно компонентное устройство и обычно собирается без суперблока, поэтому созданный массив md обеспечивает прямой доступ ко всем данным в компонентном устройстве.
Модуль FAULTY может быть запрошен для имитации отказов, чтобы позволить тестирование другие уровни MD или файловых систем. Ошибки могут запускаться по запросам чтения или записи и могут быть временными (последующее чтение / запись по адресу, вероятно, будет успешным) или постоянным (последующее чтение / запись того же адреса завершится ошибкой). Кроме того, сбои чтения могут быть «исправляемыми», что означает, что они сохраняются до тех пор, пока не поступит запрос записи по тому же адресу.
Типы сбоев могут быть запрошены с точкой. В этом случае неисправность будет повторяться повторно после заданного количества запросов соответствующего типа. Например, если постоянные ошибки чтения имеют период 100, то каждый сотый запрос чтения будет генерировать ошибку, и будет записан неисправный сектор, так что последующие чтения этого сектора также не будут выполнены.
Существует ограничение на количество запоминаемых неисправных секторов. Неисправности, возникающие после того, как этот предел исчерпан, рассматриваются как временные.
Список неисправных секторов может быть очищен, а активный список режимов отказа может быть очищен.
Параметры, управляющие этим, перечислены в mdadm (8) в разделе -p, --layout = .
При установке режима сбоя для уровня сбой возможны следующие варианты: временная запись, wt, временная запись, rt, постоянная запись, wp, постоянное чтение, rp, запись всех, исправляемое чтение, rf, clear, flush, none.
За каждым режимом отказа может следовать номер, который используется как период между возникновением отказа. Без номера ошибка генерируется один раз при первом соответствующем запросе. С номером сбой будет сгенерирован после этого количества запросов и будет продолжать генерироваться каждый раз по истечении периода.
Несколько режимов сбоя могут быть текущими одновременно, используя параметр --grow для установки последующих режимов сбоя.
12119] «очистить» или «нет» удалит любые ожидающие или периодические режимы отказа, а «очистить» удалит все устойчивые отказы.
Есть примеры из архивов списков рассылки linux-raid в разделе внедрение ошибок , которые также должны помочь вам начать работу с опциями внедрения ошибок md. =)
Tar имеет «оптимизацию», при которой он (почти) ничего не делает, если вывод / dev / null
Вы можете попробовать это, чтобы обмануть его, чтобы он все равно выполнял работу:
tar c / my / raid / device / mount / point | cat> / dev / null