2gusia (2gusia) wrote,
2gusia
2gusia

Category:

ZFS: Cannot replace a replacing device

Для памяти решил документировать редкую и неприятную ситуацию, когда при замене в zfs массиве диска заменяющий диск в процессе перестройке массива начинает сбоить и его приходится извлечь до завершения замены. В жж есть эмоциональное обсуждение проблемы. Не думаю, что текст ниже стоит читать, раньше, чем вы столкнётесь с такой проблемой, то есть на 99.9 - никогда :)

У меня лично подобная ситуация была. Как записано в history моего пула, было решено командой detach

History for 'Pool': (с сокращениями)
2011-04-06.02:09:26 zpool create -f -m /mnt/Pool Pool raidz /dev/ad4.nop /dev/ad6.nop /dev/ad8.nop /dev/ad12.nop /dev/ad16.nop /dev/ad18.nop
2011-04-10.21:13:25 zpool replace Pool /dev/ad12 /dev/ad14
2011-04-16.00:38:52 zpool detach Pool 10273301531983452669
2011-04-16.00:39:54 zpool replace Pool /dev/ad18 /dev/ad12


Но, бывает, это не помогает, ср тут. Камрад купил пачку дисков из одной партиии, собрал на них пул, работал с ними полтора года - и в один прекрасный день они дружно посыпались. Начал менять - диск тоже сдох, в результате

12            NAME                                              STATE     READ WRITE CKSUM
13            data                                              DEGRADED     0     0 4.78K
14              raidz2-0                                        DEGRADED     0     0 28.7K
15                gptid/b008179c-7ce4-11e0-804d-001b21845516    ONLINE       0     0     7
16                gptid/b092e804-7ce4-11e0-804d-001b21845516    ONLINE       0     0     0
17                gptid/b11821d9-7ce4-11e0-804d-001b21845516    ONLINE       0     0     0
18                gptid/b1a3f38d-7ce4-11e0-804d-001b21845516    ONLINE       0     0     0
19                replacing-4                                   DEGRADED     0     0     0
20                  10770492699659483544                        UNAVAIL      0     0     0  was /dev/gptid/b22ef73c-7ce4-11e0-804d-001b21845516
21                  gptid/4581fddc-3c37-11e2-9645-001b21845516  ONLINE       0     0     0
22                gptid/b2b6bdd6-7ce4-11e0-804d-001b21845516    ONLINE       0     0     0
23    
24    errors: Permanent errors have been detected in the following files:
25    
26            <metadata>:<0x23>
27            <metadata>:<0x4b>
28            <metadata>:<0x5a>


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

Если бы у нас был обычный RAID массив, было бы тяжко, сопротивляется. Обратите внимание, что массив по-прежнему доступен и очень большую часть информации с него можно скопировать. Если, не дай бог, вы попали в такую ситуацию - именно сохранением информации на другие диски и надо заняться. А потом уже пытаться лечить массив.

Камрад iZEN задал спецу вопрос и получил тут ответ

"Ага, есть такое дело, сталкивался пару раз. Для (Open)Solaris придумал достаточно некрасивый, но работающий хак:
echo zfs_no_scrub_io/W0t1 | mdb -kw
После этого надо дать resilver закончиться (он пройдёт достаточно быстро), и «zpool offline» сбойное устройство.
Потом поменять параметр назад:
echo zfs_no_scrub_io/W0t0 | mdb -kw
и «zpool replace» его работающим диском.
Принцип работы хака: мы пропускаем собственно часть, которая пишет данные; resilver заканчивается (естественно, на битый диск мы ничего не пишем, так что ошибок на нём не будет, но и данных тоже)."


NB mdb на FreeBSD нет, то есть массив для применения хака придется перетаскивать на Solaris.
Tags: zfs
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 18 comments