У меня есть настройка с btrfs, работающей поверх mdadm raid6, поскольку код btrfs RAID5/6 пока нестабилен. Я подумал, что таким образом я получу преимущества моментального снимка и контрольной суммы с несколькими дополнительными препятствиями, которые нужно преодолеть, теперь, когда мне действительно приходится преодолевать эти препятствия, у меня возникают некоторые проблемы.
Сегодня утром мой dmesg выдал следующую ошибку:
BTRFS error (device md2): bad tree block start, want 28789209759744 have 7611175298055105740
BTRFS info (device md2): read error corrected: ino 0 off 28789209759744 (dev /dev/md2 sector 55198191488)
BTRFS info (device md2): read error corrected: ino 0 off 28789209763840 (dev /dev/md2 sector 55198191496)
BTRFS info (device md2): read error corrected: ino 0 off 28789209767936 (dev /dev/md2 sector 55198191504)
BTRFS info (device md2): read error corrected: ino 0 off 28789209772032 (dev /dev/md2 sector 55198191512)
Это как раз то, что могло бы незаметно проскользнуть мимо меня, если бы я не использовал BTRFS, так что, по крайней мере, это принесло мне пользу... так что теперь я смогу выяснить, на каком диске возникла проблема, и заменить его, верно?
Что ж, mdadm, похоже, поддерживает определение неисправного диска только с помощью инструмента raid6check. Мне пришлось собрать его из исходников, чтобы он заработал в Debian, но после того, как я это сделал, похоже, я в деле.
Единственная загвоздка в том, что этот инструмент, похоже, очень медленный: сканирование 1000 полос занимает добрых 3 минуты. Это значит, что сканирование 15261512 полос, составляющих мой массив, займет более 31 дня. Я бы хотел этого избежать, если это возможно. Проверка/восстановление mdadm намного быстрее, всего около 3 дней, но не выдает никакой полезной информации о том, какой диск может быть ответственным за это, поэтому я не хочу его использовать.
Похоже, что инструмент raid6check поддерживает прием номера полосы — мне интересно, можно ли рассчитать, какой номер полосы ему передать, чтобы я мог напрямую проверить соответствующую часть диска.
Вот информация raid6check для справочных целей, если она вам поможет:
layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288
Спасибо, любые идеи приветствуются.
решение1
Хорошо, я нашел более-менее рабочий способ сделать это после разговора с JyZyXEL по поводу #linux-raid на Freenode.
raid6check сообщает об общем количестве полос, поэтому запустите его следующим образом, чтобы увидеть основную информацию, не запуская полный тест:
./raid6check /dev/md0 0 1
Вы получите что-то вроде этого:
layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288
Проверьте общее количество секторов в вашем RAID с помощью fdisk -l /dev/md0:
Disk /dev/md2: 43.7 TiB, 48008565620736 bytes, 93766729728 sectors
Теперь вычислим количество секторов на полосу:
total sectors / total stripes = 93766729728 / 15261512 = 6144
Теперь просто разделите сектор с ошибкой на количество секторов на полосу:
error sector = 55198191488/6144 = 8984080
Теперь запустите raid6check, попробуйте включить область вокруг него, так как это, похоже, не совсем точно:
raid6check /dev/md0 8984000 1000
У меня это быстро вызвало множество соответствующих ошибок, все из которых указывали на один и тот же диск, который мог выйти из строя:
Error detected at stripe 8984078, page 100: possible failed disk slot 1: 4 --> /dev/sdj1
Error detected at stripe 8984081, page 76: possible failed disk slot 4: 4 --> /dev/sdj1
С этого момента вы можете действовать соответствующим образом: заменить диск, запустить тесты SMART, использовать функцию автоматического восстановления raid6check и т. д.
Возможно, это не самый точный метод, но я публикую его на всякий случай, если никто не придумает лучшую идею и кто-то будет искать способ, который справится с этой задачей в будущем.