Лечение битого сектора на диске в рейде. Можно ли?

Question

[Георгий Н]

Есть несколько сбойных секторов на одном из двух дисков, объединенных в raid 1 (зеркало). Рейд софтовый.
Поменять диск прямо сейчас возможности нет.

Хочу попробовать "вылечить" переписав сектор командой:
hdparm --write-sector 33333333 /dev/sdb

Был бы просто диск - попробовал бы, а вот что получится при наличии рейда? Ничего плохого не случится? А то еще и сервер совсем не рядом.

Answer 1

[jcmvbkbc]

Хочу попробовать "вылечить" переписав сектор командой:
hdparm --write-sector 33333333 /dev/sdb

Вы точно прочли man hdparm? Эта команда перепишет сектор нулями.
Можно вынести битый диск из рейда и внести его обратно, что приведёт к перезаписи всех секторов на этом диске.

Comments

[Георгий Н]

Да, я в курсе про нули. Вопрос остается.

А насчет "вынести битый диск из рейда и внести его обратно" - с учетом удаленки - контроль не потеряю?

[jcmvbkbc]

> Да, я в курсе про нули. Вопрос остается.
Получите +1 в mismatch_cnt. mdraid не умеет восстанавливать битые данные сам.

> А насчет "вынести битый диск из рейда и внести его обратно" - с учетом удаленки - контроль не потеряю?
Ну только если у вас rootfs на этом рейде и первый диск навернётся до того, как второй синхронизируется.

[Георгий Н]

> Получите +1 в mismatch_cnt. mdraid не умеет восстанавливать битые данные сам.
Вобщем-то, это ничем не грозит, как я понимаю? А если аналогично затереть тот же сектор (с тем же номером) на другом диске?

> Ну только если у вас rootfs на этом рейде
На нем... Все на нем...

[jcmvbkbc]

> Вобщем-то, это ничем не грозит, как я понимаю? А если аналогично затереть тот же сектор (с тем же номером) на другом диске?
Если там нет данных, то почему просто не отметить бэд в файловой системе?

[Георгий Н]

> Если там нет данных, то почему просто не отметить бэд в файловой системе?

А как это сделать? Данные есть, но не критичные. Если это как-то поможет, то было бы неплохо.

Вообще, суть в чем - периодически что-то пытается обратиться к файлу, который и расположен в этом секторе. При обращении к файлу все начинает дико тупить, моментально подпрыгивает wa, la. В сислоге ошибки диска, указывающие на этот сектор. Пытался искать файл, чтобы исключить его из обработки - более чем уверен, что это пользовательские данные. Искал по inode (из сислога), но на несколько-требайтном винте это проблематично - долго и опять же - wa, la растет. А с сервером в это время активно пользователи работают. Поэтому конца поиска не дожидался.

Answer 2

[Владимир]

не нужно оперировать с секторами диска

алгоритм примерно такой для ext2/ext3/ext4
смотрите размер блока файловой системы

# dumpe2fs /dev/md1 | grep 'Block size'

сканируете badblocks, указав размер блока вместо block_size с выхлопом в файл списка битых блоков

# badblocks -b block_size -o /tmp/bad.log /dev/md1

смотрите в /tmp/bad.log
если немного нашлось и хочется посмотреть какие файлы побиты

# debugfs
debugfs 1.42.12 (29-Aug-2014)
debugfs: open /dev/md1
debugfs: testb 24864
Block 24864 not in use -- этот блок не используется никаким файлом
debugfs: testb 24865
Block 24865 marked in use -- а этот юзается. смотрим какой inode он принадлежит
debugfs: icheck 24865
Block Inode number
24865 32901
debugfs: ncheck 32901
Inode Pathname
32901 /grub/i386-pc/gcry_des.mod

пометить битые блоки в файловой системе

# e2fsck -l /tmp/bad.log /dev/md1