ext4 на неисправных дисках. Как избежать перемонтирования только для чтения?

Эта проблема:

Я отвечаю за кластер Hadoop из 44 узлов. У нас есть накопители WD Green Drive емкостью 1,5 ТБ с (совершенно неизвестной) проблемой числа циклов загрузки.

Эти диски работают нормально, но по мере взросления они показывают все больше плохих блоков. Перезапись этих плохих блоков работает в течение некоторого времени, но они вновь появляются в разных местах.

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

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

    • остановите службы Hadoop, размонтируйте диски, найдите поврежденные блоки, используя dmesg выход и smartctl и переписать эти плохие блоки с hdparm --write-sector,
    • Бег fsck -f -y на диске и перемонтируйте его.

  2. Держите систему стабильной.

    • Hadoop заботится об ошибках диска (избыточность в 3 раза), но я бы не хотел рисковать поврежденными файловыми системами.

Что я сделал?

На данный момент я изменил mount варианты:

  • erros=continue,noatime но я получаю скрытый доступ только для чтения из-за ошибок в журнале.

Затем я попытался отключить журнал:

  • tune2fs -O ^has_journal это позволяет избежать перемонтирования только для чтения, но, похоже, повреждает файловую систему (что имеет смысл, нет журнала)

Сейчас я думаю о переходе на

  • tune2fs -o journal_data_writeback а также mount с data=writeback,nobh,barrier=0

Но я не уверен, если это повторно вводит только для чтения перемонтирует.

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

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

Источник

2 ответа

Решение

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

Источник

Если вам АБСОЛЮТНО нужно использовать эти диски, я бы порекомендовал сделать файловые системы с mkfs -c -c… чтобы mkfs проверил наличие плохих блоков.

Вы можете попробовать другую файловую систему, такую ​​как btrfs, и посмотреть, работает ли она лучше, но в конечном итоге правильный ответ - "заменить диски".

Источник
Другие вопросы по тегам