Здравствуйте!FreeBSD 8.1 STABLE amd64 стоит на пуле ZFS из 4-х зеркал по 2 диска.
При этом первые 2 диска разбиты на GPT (1-загрузчик, 2-своп, 3-в ZFS mirror).Один из дисков (5-й) стал выдавать очень много ошибок чтения. Его перевели в offline, вытащили и отдали в гарантию.
Затем, сервер был перезагружен (штатно, для установки доп.памяти). Но не загрузился :(
Загрузчик пишет:
FreeBSD/i386 ZFS enabled bootstrap loader, Revision 1.1
...
/boot/kernel/kernel text-0x916f2f data=0x12d918+0xc53d8d1cbb]
/boot/kernel/zfs.ko size 0x19e010 ar 0xec0000
loading required module 'opensolaris'
/boot/kernel/opensolaris.ko size 0x3860 at 0x105f000
ZFS: i/o error - all block copies unavailable
....После чего фря грузится дальше, но, дойдя до монтирования корня, пишет,
что не может смонтировать его из zfs:tankНе понятно, как такое могло случиться, ведь извлечен был диск из зеркала. А сервер надо срочно запустить.
Странно, что в вышеуказанной ошибке пишется i386, хотя ядро amd64. Ранее не замечал, но ничего не менялось.
Для полноты картины опишу доп.информацию.
Кроме диска 5,ошибки давал диск 1, но гораздо реже, и, поэтому, был оставлен в пуле.
Оба этих диска были зазеркалированы с другими, работоспособными.Вся последовательность действий такова:
da5 был переведен в offline. Затем также в offline был переведен da1.
Затем, вгорячую был извлечен da4 (зазеркалированный с ad12) и поменян местами в отсеках с da5. После манипуляции имена дисков не поменялись (аппаратный RAID их помнит). Затем все были переведены в online. Resilvering закончился удачно.Ещё позднее da5 был снова переведен в offline и извлечен. Всё это время на пуле была активность и всё работало нормально.
Затем в /boot/loader.conf увеличен размер kmem и zfs.arcsize,
сервер выключен, установлена доп. память и дополнительный диск (ad4).После включения, сервер не хочет грузиться, как было указано выше.
Возврат da4 в прежний слот, перестановка местами da0 и da1 ничего не меняют.
Очень прошу помощи в починке пула!
С live CD загрузить ZFS не смог, т.к. zfs.ko там найти не удалось (только zfs.ko* в папке dist, который не грузится)
Для полноты картины не помешал бы вывод zpool status, если он где-нибудь сохранился, ну или конфигурация пула в такой же нотации.Как насчет загрузиться с LiveCD с OpenSolaris и посмотреть, что получится?
>Для полноты картины не помешал бы вывод zpool status, если он где-нибудь
>сохранился, ну или конфигурация пула в такой же нотации.К сожалению, видимо, не сохранял
Конфигурация такая
tank:
mirror
da0p3
da1p3
mirror
da2
da3
mirror
da4
ad12
mirror
da5
ad14Потом было сделано
zpool offline tank da5после чего все работало прекрасно
>
>Как насчет загрузиться с LiveCD с OpenSolaris и посмотреть, что получится?Спасибо за совет, попробую. Затрудняет ещё то, что сервер удаленный. А консоль со сторонних дисков не заработает.
>>Для полноты картины не помешал бы вывод zpool status, если он где-нибудь
>>сохранился, ну или конфигурация пула в такой же нотации.
>
>К сожалению, видимо, не сохранялПолучилось посмотреть конфигурацию из загрузчика, нажав F12 во время его старта
и затем дав команду status/boot.config: -Dh
FreeBSD/i386 boot
Default: tank:/boot/zfsloader
boot: status pool: tank
config:NAME STATE
tank ONLINE
mirror ONLINE
da0p3 ONLINE
da1p3 ONLINE
mirror ONLINE
da2 ONLINE
da3 ONLINE
mirror ONLINE
da4 ONLINE
ad12 ONLINE
Получается, что не виден ad14, парой у которого был da5
Тогда понятно, почему не собирается.
Но куда он делся?
Контроллер его находит вместе с ad12:Intel(R) Embedded Server RAID Technology II Version A.01.01021804I [PCI 0/1F] Intel(R) Embedded Server RAID Technology II
Scanning for Port 4... Responding. WDC WD2001FASS-00U 1907217MB
Scanning for Port 5... Responding. WDC WD2001FASS-00W 1907217MBКак и da диски:
SLOT ID LUN VENDOR PRODUCT REVISION CAPACITY
---- --- --- -------- ---------------- ---------- ----------
0 0 0 ATA WDC WD2001FASS-0 0101 1907729 MB
0 2 0 ATA WDC WD2001FASS-0 0101 1907729 MB
0 3 0 ATA WDC WD2001FASS-0 0101 1907729 MB
0 4 0 ATA WDC WD2001FASS-0 0101 1907729 MB
0 5 0 ATA WDC WD2001FASS-0 0101 1907729 MB
0 LSILogic SAS1068-IT 1.11.01.00И ядро при загрузке тоже находит!
uhub4: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4
acd0: CDRW <Slimtype COMBO SSC-2485K/5K04> at ata0-slave UDMA33
ad12: 1907729MB <WDC WD2001FASS-00U0B0 01.00101> at ata6-master UDMA100 SATA 3Gb/s
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
ad14: 1907729MB <WDC WD2001FASS-00W2B0 01.00101> at ata7-master UDMA100 SATA 3Gb/s
ipmi0: IPMI device rev. 1, firmware rev. 0.2, version 2.0
Как же он смог выпасть из пула? detach ему точно не говорили (и он бы не сработал, судя по информации от apl).
Или табличка status в загрузчике не выводит всех строк?
P.S. Может на время попыток восстановления, вынуть диски, зеркальные оставшимся, чтобы случайно на них не попортить конфигурацию?
>[оверквотинг удален]
>Потом было сделано
>zpool offline tank da5
>
>после чего все работало прекрасно
>
>>
>>Как насчет загрузиться с LiveCD с OpenSolaris и посмотреть, что получится?
>
>Спасибо за совет, попробую. Затрудняет ещё то, что сервер удаленный. А консоль
>со сторонних дисков не заработает.
Поищи крайний frenzy. с него скорее всего получиться посмотреть как выглядит система. но скорее всего там каша.похорошему диски из миррора надо было извлекать с помощью
zpool detach pool device
Detaches device from a mirror. The operation is refused if there
are no other valid replicas of the data.если все диски в наличии, попробуй собрать все как было вначале или подняться со второй пары.
>Поищи крайний frenzy. с него скорее всего получиться посмотреть как выглядит система.Спасибо за совет! Попробую.
>но скорее всего там каша.
>
>похорошему диски из миррора надо было извлекать с помощью
>
>zpool detach pool device
> Detaches
> device from a mirror. The operation is refused
>if there
> are
>no other valid replicas of the data.Я не использовал detach после того, как использовал его для перестановки диска в другой слот. В результате он стал снова синхронизоваться...
Согласен, что в случае увоза диска куда-то, это стоит сделать.Но мне непонятно, как ZFS может потерять все от потери диска в зеркале! Какой тогда смысл зеркалирования? А если диск просто таки полностью сдохнет, тогда что?
>
>если все диски в наличии, попробуй собрать все как было вначале или
>подняться со второй пары.Диск этот теперь добыть, видимо, нереально, или сложно. Возможно в ходе проверки на неработоспособность его отформатировали и т.п.
А что значит со второй пары? Отключить все вторые диски в зеркалах? Или как раз поставить старый, а все парные отключить.
А смысл выводить диск в офлайн? Какая изначально задача стояла?Если надо было временно заменить диск, то все равно потом ресинк делать.
при переводе диска в офлайн, его журнал пишется на другой диск, когда потом его выводишь в онлайн журнал сливается на этот диск. Так что выяснить что пул делал с оставшимися дисками -- ХЗ.
Попробуй взять по одному диску из каждого зеркала и завестись с frenzy. потом симпортируй пул. посмотри что получится.
>А смысл выводить диск в офлайн? Какая изначально задача стояла?
>
>Если надо было временно заменить диск, то все равно потом ресинк делать.Сначала надо было его временно отключить, чтобы посмотреть, будет ли лучше работать система (т.к. этот диск тормозил её ошибками чтения).
Согласен, что перед извлечение можно было его и detach.
Но всё равно система должна подразумевать ситуацию, когда диск внезапно полностью ломается.
>
>
>при переводе диска в офлайн, его журнал пишется на другой диск, когда
>потом его выводишь в онлайн журнал сливается на этот диск. Так
>что выяснить что пул делал с оставшимися дисками -- ХЗ.Значит нагрузка на другие диски возрастает? Но не должен же он был испортить их.
>
>Попробуй взять по одному диску из каждого зеркала и завестись с frenzy.
>потом симпортируй пул. посмотри что получится.
И ещё, в инете нашел, что в loader prompt в списке модулей lsmod должен присутствовать
zpool.cache
У меня такого нет (только zfs.ko, opensolaris.ko)Может ли это быть причиной того, что ad14 не виден ZFSу?
>[оверквотинг удален]
>>потом его выводишь в онлайн журнал сливается на этот диск. Так
>>что выяснить что пул делал с оставшимися дисками -- ХЗ.
>
>Значит нагрузка на другие диски возрастает? Но не должен же он
>был испортить их.
>
>
>>
>>Попробуй взять по одному диску из каждого зеркала и завестись с frenzy.
>>потом симпортируй пул. посмотри что получится.
>Сначала надо было его временно отключить, чтобы посмотреть, будет ли лучше работать
>система (т.к. этот диск тормозил её ошибками чтения).Если есть ошибки, то лучше менять
и zpool status/zpool scrub.>Согласен, что перед извлечение можно было его и detach.
>Но всё равно система должна подразумевать ситуацию, когда диск внезапно полностью ломается.Да, но тогда пул становится degraded, а диск fault. И Dirty Time Log для него не будет создаваться.
>Значит нагрузка на другие диски возрастает? Но не должен же он
>был испортить их.Возрастет но не на много. Как говорят знающие люди.
Не должен был, но выключением машины ты мог прервать его внутреннюю работу на пол дороги. Сами диски меняли в серверах "наживо" не один десяток раз. Все было нормально.
>при переводе диска в офлайн, его журнал пишется на другой диск, когда
>потом его выводишь в онлайн журнал сливается на этот диск. Так
>что выяснить что пул делал с оставшимися дисками -- ХЗ.Это неправильное представление. Когда диск оффлайнится, для него создается объект в пуле, называемый Dirty Time Log, в который записываются диапазоны номеров групп транзакций, во время которых этот диск отсутствовал. Этот объект как правило невелик в размерах. Потом, если тот же самый диск появляется обратно, на него в процессе resilvering записываются только блоки, порожденные в то время, пока диск отсутствовал. После завершения процесса объект Dirty Time Log уничтожается.
>>при переводе диска в офлайн, его журнал пишется на другой диск, когда
>>потом его выводишь в онлайн журнал сливается на этот диск. Так
>>что выяснить что пул делал с оставшимися дисками -- ХЗ.
>
>Это неправильное представление. Когда диск оффлайнится, для него создается объект в пуле,
>называемый Dirty Time Log, в который записываются диапазоны номеров групп транзакций,
>во время которых этот диск отсутствовал. Этот объект как правило невелик
>в размерах. Потом, если тот же самый диск появляется обратно, на
>него в процессе resilvering записываются только блоки, порожденные в то время,
>пока диск отсутствовал. После завершения процесса объект Dirty Time Log уничтожается.Согласен. т.е. пишится не сам журнал, а скорее индексы на транзакции.
Я не знаю механизма, как повел себя пул при переводе диска сначала в офлайн (начинает создаваться Dirty time log), а после этого диск вынули.если бы диск просто вынули, проблем было бы, скорее всего, меньше.
>Я не использовал detach после того, как использовал его для перестановки диска
>в другой слот. В результате он стал снова синхронизоваться...Похоже где-то тут собака и порылась... Теперь, когда есть более четкое описание конфигурации, надо посмотреть внимательно на описание твоих действий.
>Но мне непонятно, как ZFS может потерять все от потери диска в зеркале!
Тут дело не в том, что ты потерял диск в зеркале, а в том, что в результате какой-то последовательности событий ты потерял Top-Level VDEV в пуле, а есть совсем нехорошо.
> Какой тогда смысл зеркалирования? А если диск просто таки полностью сдохнет, тогда что?
Все было бы хорошо, если бы не было вопросов ко второму диску в зеркале. Надо разбираться с ним.. У тебя есть возможность запустить zdb -l /dev/ad14 ? Загрузившись из сети, например?
>>Я не использовал detach после того, как использовал его для перестановки диска
>>в другой слот. В результате он стал снова синхронизоваться...
>
>Похоже где-то тут собака и порылась... Теперь, когда есть более четкое описание
>конфигурации, надо посмотреть внимательно на описание твоих действий.Полная последовательность действий.
1. Устанавливали новые диски.
До этого конфигурация зеркал была
da0 - da1
da2 - da3
da4 - da5среди них сбойного ещё не было (кроме того, что da1 изредка давал ошибки).
Для разнесения половинок RAID по разным корпусам (ad стоят в соседнем копрусе), решили
туда перенести старый da5.
Вместо offline, при этом, сделали detach. И поставили его в ad12. Он потом долго синхронизовался (о чем я и писал выше), но работал корректно, и сейчас тоже виден.А на места da5 и ad14 были поставлен новые диски, и тоже объединены в mirror.
Перестановка дисков производилась при выключенном (корректно) сервере. И он после того загрузился.Получилось.
da0 - da1
da2 - da3
da4 - ad12
da5* - ad14**-новые диски
2. Диск da5 (новый) стал давать всё больше ошибок чтения.
Перевели его в offline, чтобы дать системе нормально работать.На следующий день решили проверить, не от отсека ли это зависит.
В горячую вынули da4 ("для проверки отработки ZFSом таких ситуаций :) :( )
и поменяли местами с da5.
Затем только дали команду camcontrol rescan all.Контроллер LSI, при этом, имена им оставил прежними. Но неизвестно, как они виделись ДО rescan. Однако, ZFS же должен видеть их по метке, а не по имени диска, и вряд ли мог записать что-то не на тот диск до обновления информации со стороны контроллера.
После этой манипуляции диски довольно быстро синхронизовались (resilver), даже долго отключенный da5.
3. Ещё позже, диск da5 был снова переведен в offline (тут ошибка в том, что не detach, ведь знали, что возвращать его не придется), извлечен и сдан по гарантии.
4. В конфиг сервера были прописаны параметры для бОльшего объема памяти, он выключен, увеличена память (с 11 до 19 Гб) и вставлен SSD диск в ad4.
При загрузке - появилась вышеуказанная ошибка.
Отключение SSD (ad4), перестановка в отсеках (в выключенном состоянии сервера) других дисков ни к чему не привели.
>[оверквотинг удален]
>
>Тут дело не в том, что ты потерял диск в зеркале, а
>в том, что в результате какой-то последовательности событий ты потерял Top-Level
>VDEV в пуле, а есть совсем нехорошо.
>
>> Какой тогда смысл зеркалирования? А если диск просто таки полностью сдохнет, тогда что?
>
>Все было бы хорошо, если бы не было вопросов ко второму диску
>в зеркале. Надо разбираться с ним.. У тебя есть возможность запустить
>zdb -l /dev/ad14 ? Загрузившись из сети, например?Посмотрю, когда смогу попасть на площадку.
А есть ли дистрибутивы, которые через консольный порт работают? Я бы тогда смог загрузить их удаленно. Видимо, можно самому такой сделать, но сейчас нет времени.
Когда делаете в FreeBSD ZFS- массивы, то надо ОБЯЗАТЕЛЬНО делать раздел GPART с МЕТКОЙ и создавать массивы используя метки диска.
[ /usr/ports ] > zpool status [shuba@testbestie]
pool: zroot
state: ONLINE
scrub: none requested
config:NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror ONLINE 0 0 0
gpt/disk1 ONLINE 0 0 0
gpt/disk0 ONLINE 0 0 0errors: No known data errors
[ /usr/ports ] >Тогда можно гарантировать, что при перемещении диска массив не развалится.
>[оверквотинг удален]
>gpt/disk1 ONLINE 0
> 0 0
>
>gpt/disk0 ONLINE 0
> 0 0
>
>errors: No known data errors
>[ /usr/ports ] >
>
>Тогда можно гарантировать, что при перемещении диска массив не развалится.Спасибо, понял. Метки то были, но в пул добавлял по именам устройств... ZFS же всё равно должен смотреть на свои метки.
А теперь то что делать?
>Спасибо, понял. Метки то были, но в пул добавлял по именам
>устройств... ZFS же всё равно должен смотреть на свои метки.Я не уверен, что пул работает с дисками по их именам.
По крайней мере при перемещении диска с пулом на другой порт контроллера, при новом старте системы с пулом никаких проблем небыло.
>А теперь то что делать?
Подниматься с бэкапа..
>[оверквотинг удален]
>
>Тут дело не в том, что ты потерял диск в зеркале, а
>в том, что в результате какой-то последовательности событий ты потерял Top-Level
>VDEV в пуле, а есть совсем нехорошо.
>
>> Какой тогда смысл зеркалирования? А если диск просто таки полностью сдохнет, тогда что?
>
>Все было бы хорошо, если бы не было вопросов ко второму диску
>в зеркале. Надо разбираться с ним.. У тебя есть возможность запустить
>zdb -l /dev/ad14 ? Загрузившись из сети, например?Загрузился в frenzy. zpool import показывает что все ок.
zdb -l /dev/ada1 (так там стал называться ad14):
показывает 4 раза метку, видимо, одну и ту же (резерв?) первый взгляд, корректную--------------------------------------------
LABEL 0
--------------------------------------------
version=14
name='tank'
state=0
txg=72605372
pool_guid=6706252901631390582
hostid=2309068031
hostname='*'
top_guid=13967584634772848356
guid=13751120050166965739
vdev_tree
type='mirror'
id=3
guid=13967584634772848356
metaslab_array=650
metaslab_shift=34
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=7528861477485455434
path='/dev/da5'
whole_disk=0
DTL=649
offline=1
children[1]
type='disk'
id=1
guid=13751120050166965739
path='/dev/ad14'
whole_disk=0
DTL=648
--------------------------------------------
LABEL 1
--------------------------------------------
version=14
name='tank'
state=0
txg=72605372
pool_guid=6706252901631390582
hostid=2309068031
hostname='*'
top_guid=13967584634772848356
guid=13751120050166965739
vdev_tree
type='mirror'
id=3
guid=13967584634772848356
metaslab_array=650
metaslab_shift=34
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=7528861477485455434
path='/dev/da5'
whole_disk=0
DTL=649
offline=1
children[1]
type='disk'
id=1
guid=13751120050166965739
path='/dev/ad14'
whole_disk=0
DTL=648
--------------------------------------------
LABEL 2
--------------------------------------------
version=14
name='tank'
state=0
txg=72605372
pool_guid=6706252901631390582
hostid=2309068031
hostname='*'
top_guid=13967584634772848356
guid=13751120050166965739
vdev_tree
type='mirror'
id=3
guid=13967584634772848356
metaslab_array=650
metaslab_shift=34
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=7528861477485455434
path='/dev/da5'
whole_disk=0
DTL=649
offline=1
children[1]
type='disk'
id=1
guid=13751120050166965739
path='/dev/ad14'
whole_disk=0
DTL=648
--------------------------------------------
LABEL 3
--------------------------------------------
version=14
name='tank'
state=0
txg=72605372
pool_guid=6706252901631390582
hostid=2309068031
hostname'*'
top_guid=13967584634772848356
guid=13751120050166965739
vdev_tree
type='mirror'
id=3
guid=13967584634772848356
metaslab_array=650
metaslab_shift=34
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=7528861477485455434
path='/dev/da5'
whole_disk=0
DTL=649
offline=1
children[1]
type='disk'
id=1
guid=13751120050166965739
path='/dev/ad14'
whole_disk=0
DTL=648
Для сравнения -метка от da4:
--------------------------------------------
LABEL 0
--------------------------------------------
version=14
name='tank'
state=0
txg=72604289
pool_guid=6706252901631390582
hostid=2309068031
hostname='*'
top_guid=14631550544816015141
guid=10976838175571496472
vdev_tree
type='mirror'
id=2
guid=14631550544816015141
whole_disk=0
metaslab_array=257
metaslab_shift=33
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=10976838175571496472
path='/dev/da4'
whole_disk=0
DTL=501
children[1]
type='disk'
id=1
guid=12764619093800710973
path='/dev/ad12'
whole_disk=0
DTL=495
--------------------------------------------
LABEL 1
--------------------------------------------
version=14
name='tank'
state=0
txg=72604289
pool_guid=6706252901631390582
hostid=2309068031
hostname='*'
top_guid=14631550544816015141
guid=10976838175571496472
vdev_tree
type='mirror'
id=2
guid=14631550544816015141
whole_disk=0
metaslab_array=257
metaslab_shift=33
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=10976838175571496472
path='/dev/da4'
whole_disk=0
DTL=501
children[1]
type='disk'
id=1
guid=12764619093800710973
path='/dev/ad12'
whole_disk=0
DTL=495
--------------------------------------------
LABEL 2
--------------------------------------------
version=14
name='tank'
state=0
txg=72604289
pool_guid=6706252901631390582
hostid=2309068031
hostname='*'
top_guid=14631550544816015141
guid=10976838175571496472
vdev_tree
type='mirror'
id=2
guid=14631550544816015141
whole_disk=0
metaslab_array=257
metaslab_shift=33
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=10976838175571496472
path='/dev/da4'
whole_disk=0
DTL=501
children[1]
type='disk'
id=1
guid=12764619093800710973
path='/dev/ad12'
whole_disk=0
DTL=495
--------------------------------------------
LABEL 3
--------------------------------------------
version=14
name='tank'
state=0
txg=72604289
pool_guid=6706252901631390582
hostid=2309068031
hostname='*'
top_guid=14631550544816015141
guid=10976838175571496472
vdev_tree
type='mirror'
id=2
guid=14631550544816015141
whole_disk=0
metaslab_array=257
metaslab_shift=33
ashift=9
asize=2000394125312
is_log=0
children[0]
type='disk'
id=0
guid=10976838175571496472
path='/dev/da4'
whole_disk=0
DTL=501
children[1]
type='disk'
id=1
guid=12764619093800710973
path='/dev/ad12'
whole_disk=0
DTL=495
top_guid другой... но они и у других зеркал различаются (одинаковые в пределах зеркала).
guid различаются у каждого диска
hostid и pool_guid у всех одинаковые,
а вот txg у ada1 (ad4) отличается.... у всех он 72604289 , а у него 72605372 :(Но, может быть, это из за того, что с пула пытались читать после того, как он уже не видел этот диск?
Что можно теперь сделать?
Мне приходит на ум - импортировать пул и удалить с него zpool.cache
>Поищи крайний frenzy. с него скорее всего получиться посмотреть как выглядит система.
>но скорее всего там каша.Из frenzy по zpool import показывает пул в том виде, в каком он и должен быть.
Вопрос - импортировать ли его там, или это опасно?
После импорта. Думаю, надо стереть zpool.cache, и попробовать загрузиться.
>[оверквотинг удален]
>
>zpool detach pool device
> Detaches
> device from a mirror. The operation is refused
>if there
> are
>no other valid replicas of the data.
>
>если все диски в наличии, попробуй собрать все как было вначале или
>подняться со второй пары.
>>Поищи крайний frenzy. с него скорее всего получиться посмотреть как выглядит система.
>>но скорее всего там каша.
>
>Из frenzy по zpool import показывает пул в том виде, в каком
>он и должен быть.
>
>Вопрос - импортировать ли его там, или это опасно?
>
>После импорта. Думаю, надо стереть zpool.cache, и попробовать загрузиться.Хуже в любом случае уже не будет.
При импорте пула с самим пулом уже ничего не произойдет.
бэкап данных есть?
>[оверквотинг удален]
>>Из frenzy по zpool import показывает пул в том виде, в каком
>>он и должен быть.
>>
>>Вопрос - импортировать ли его там, или это опасно?
>>
>>После импорта. Думаю, надо стереть zpool.cache, и попробовать загрузиться.
>
>Хуже в любом случае уже не будет.
>При импорте пула с самим пулом уже ничего не произойдет.
>бэкап данных есть?Нету, там и так 8Тб зазеркалено, куда уж ещё и бакап держать... Снапшоты вопрос восстановления версий решают.
Но по такому поведению ZFS лучже уж без зеркал а на вторые диски делать бекапы периодически...
>[оверквотинг удален]
>>Из frenzy по zpool import показывает пул в том виде, в каком
>>он и должен быть.
>>
>>Вопрос - импортировать ли его там, или это опасно?
>>
>>После импорта. Думаю, надо стереть zpool.cache, и попробовать загрузиться.
>
>Хуже в любом случае уже не будет.
>При импорте пула с самим пулом уже ничего не произойдет.
>бэкап данных есть?Импортировал. Несмотря на разные txg, все нормально появилось. Все данные на месте.
Даже сделал detach удаленному ранее диску, не ругнулось.Не экспортировал и перезагрузил (нормально).
Только система всё равно не грузится с него (та же ошибка). Что теперь с ним делать :) ?
Правда, я не нашел zpool.cache в /etc на загрузочной системе пула. И соотв. не удалял его. А где он может быть?
>[оверквотинг удален]
>месте.
>Даже сделал detach удаленному ранее диску, не ругнулось.
>
>Не экспортировал и перезагрузил (нормально).
>
>Только система всё равно не грузится с него (та же ошибка). Что
>теперь с ним делать :) ?
>
>Правда, я не нашел zpool.cache в /etc на загрузочной системе пула. И
>соотв. не удалял его. А где он может быть?Ура!!! Все заработало.
Воспользовался этим http://forums.freebsd.org/showthread.php?t=4185 описание замены zpool.cache
Огромное спасибо всем, кто помогал!
Чуть позже опишу подробней действия.
>Ура!!! Все заработало.
>Воспользовался этим http://forums.freebsd.org/showthread.php?t=4185 описание замены zpool.cacheНу и Слава Богу!
А про бэкап подумай. не обязательно на той-же машине.
>>[оверквотинг удален]
>Импортировал. Несмотря на разные txg, все нормально появилось. Все данные на
>месте.
>Даже сделал detach удаленному ранее диску, не ругнулось.Тут имеет смысл сбекапить с него данные, чтобы не навернуть в последующих плясках.
[apl@store] [/home/apl]: ls -la /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 3460 10 июн 09:37 /boot/zfs/zpool.cache
>Только система всё равно не грузится с него (та же ошибка). Что
>теперь с ним делать :) ?После бэкапа запустить zpool scrub. посмотреть, что он на это скажет.
>
>Один из дисков (5-й) стал выдавать очень много ошибок чтения. Его перевели
>в offline, вытащили и отдали в гарантию.
>
>Затем, сервер был перезагружен (штатно, для установки доп.памяти). Но не загрузился
>:(http://habrahabr.ru/blogs/bsdelniki/77722/
Гляньте. Может найдете что-то полезное для себя.
>>
>>Один из дисков (5-й) стал выдавать очень много ошибок чтения. Его перевели
>>в offline, вытащили и отдали в гарантию.
>>
>>Затем, сервер был перезагружен (штатно, для установки доп.памяти). Но не загрузился
>>:(
>
>http://habrahabr.ru/blogs/bsdelniki/77722/
>Гляньте. Может найдете что-то полезное для себя.Спасибо!
Только Хабр похоже ни у кого не работает....