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