Учитывая мои четыре диска RAIDZ1, один диск стал физически шумным, пока не выдает ошибок, но и не звучит исправно. Поэтому я решил заранее заменить его.
Я сделал:
zpool offline tank0 ad6
Выключение, извлечение и замена диска
zpool replace tank0 ad6 ad6
который висит вечно.
zpool status
тоже висит вечно, как и zpool history
.
Если я перезагружу машину с удаленным диском, все будет работать нормально, в ухудшенном режиме, как и ожидалось.
Что мне теперь делать? Обеспокоен, потому что мои данные теперь уязвимы для отказа одного диска.
ОС - FreeBSD 7.3-RELEASE-p1 - также известная как FreeNAS 7.0.2.5226
Я только что попробовал ту же операцию на виртуальной машине, хотя FreeBSD 7.3-RELEASE-p7 (FreeNAS 0.7.2.8191, немного более поздняя версия) - работает отлично. Пробую использовать самую старую версию FreeNAS, которую я могу найти сейчас (7.0.2.5799), и обновлю ее позже.
Кроме того, делает zpool replace
не требует использования файловой системы? Есть вероятность, что другой демон на NAS использует файловую систему. я предполагать это было бы нормально, но это, конечно, может быть неправильно.
Обновление, 2012-01-10
Я загрузил машину с FreeNAS 8 и сделал zpool replace
- который начался и сразу же начал бросать груды ошибок повреждения данных и паники ядра - несмотря на то, что еженедельная очистка пула так и не обнаружила никаких проблем. Не думаю, что я сделал что-то глупое, например, сказал ему заменить не тот диск. Я сразу выдал shutdown -h
поскольку я знаю, что данные были в порядке.
Как бы то ни было, теперь у меня деградированный пул, застрявший в состоянии, когда замена приостановлена, и я копирую свои данные на внешний диск емкостью 3 ТБ, купленный за большие деньги, поэтому я могу уничтожить пул и начать заново. К счастью, данные выглядят нормально - у меня есть md5sums около 100 ГБ файлов, которые пока кажутся нетронутыми, и мне удалось восстановить все, что действительно незаменимо.
Теперь я жду, когда прибудет больше ОЗУ, поскольку FreeNAS 8 продолжает паниковать из-за слишком малых ошибок kmem_max, которые я, кажется, не могу настроить, и машина была ограничена ОЗУ (1 ГБ ОЗУ для 4 ТБ RAIDZ1).
Жесткий урок извлечен из резервного копирования, но и доверие к ZFS / FreeNAS / FreeBSD действительно подорвано.
ОБНОВЛЕНИЕ 13.01.12
Что ж, теперь мои данные, похоже, надежно сохранены.
zpool status -v зависает, даже если для продолжения установлен режим отказа. Вот вывод статуса zpool с подключенным новым диском (ada1)
pool: tank0
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the entire pool
from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank0 DEGRADED 0 0 0
raidz1 DEGRADED 0 0 0
ada2 ONLINE 0 0 0
ada3 ONLINE 0 0 0
ada0 ONLINE 0 0 0
replacing DEGRADED 0 0 3.17K
6540253751212815210 UNAVAIL 0 0 0 was /dev/ada3/old
ada1 ONLINE 0 0 0
errors: 3130 data errors, use '-v' for a list
Если старый диск подключен вместо нового, ZFS не будет импортировать пул и zfs status
говорит:
tank0 UNAVAIL insufficient replicas
raidz1 FAULTED corrupted data
ada2 ONLINE
ada3 ONLINE
ada0 FAULTED corrupted data
replacing UNAVAIL insufficient replicas
ada1 FAULTED corrupted data
ada1 FAULTED corrupted data
Я не понимаю, почему ada0 должен быть ОТКАЗАН при подключении нового диска (ada1), но ОНЛАЙН при подключенном старом диске? Я не понимаю, как вообще связано ada0.
Попробуем восстановить этот бассейн в качестве обучающего упражнения.
Был действительно загнан в угол с этим. Закончили сглаживанием пула и восстановлением файлов из резервной копии на FreeNAS 8.
Пока что кажется более стабильным - более новая ОС x64 и 4 ГБ ОЗУ, вероятно, вносят свой вклад.
Я не гуру ZFS, но сделаю снимок: похоже, подсистема ZFS все еще пытается получить доступ к неисправному диску и по какой-то причине зависает. Попробуйте установить пул failmode
ценность для continue
(zpool set failmode=continue
) и посмотрите, избавит ли это от зависания и позволит ли вам разобраться в том, что происходит.
(Обратите внимание, что это не исправление: система по-прежнему не может получить доступ к диску, который, по ее мнению, должен иметь доступ, она просто сообщает ей вернуть ошибку и продолжить работу, а не блокировать до получения ответа.)
У меня недавно была ситуация, которая звучит похоже, хотя у меня не было зависаний, я просто не мог заменить неисправный диск. Конечно, я был в совершенно другой среде: Linux с ZFS-fuse. Однако, в отличие от вас, мне не сказали, что я испытала повреждение данных, я видел:
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://www.sun.com/msg/ZFS-8000-2Q
[...]
disk/by-id/ata-Hitachi_HDS722020ALA330_JK1105B8GNNADX-part4 UNAVAIL 0 0 0 cannot open
Теперь, прежде чем идти дальше, важно понять, что ни одна из данных в этом пуле не была незаменимой, все было либо в резервной копии, либо в резервных копиях других систем. Если у вас нет хороших резервных копий этих данных, вы, вероятно, захотите остановиться на этом этапе и сделать необработанные копии дисков, прежде чем делать что-либо еще, на случай, если это ухудшит ситуацию.
В итоге я сделал вот что.
Сначала я экспортировал пул с помощью «zfs export POOLNAME». Затем я перезагрузился и сделал «zfs import POOLNAME».
Теперь, когда я сделал "zpool status", я получил следующее:
state: DEGRADED
[...]
12640132412556728613 UNAVAIL 0 0 0 was /dev/disk/by-id/ata-Hitachi_HDS722020ALA330_JK1105B8GNNADX-part4
Теперь я смог использовать указанный выше номер для замены диска, используя:
zpool replace POOLNAME 12640132412556728613 /dev/DEVILCENAME
Теперь это проявилось как замена диска в "статусе zpool":
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress for 0h0m, 0.00% done, 282h43m to go
Для его работы потребовалось около 48 часов, а не 282 часа. :-)