zfs + freebsd. i/o error - all block copies unavailable.

Phoenix

Что есть:
zfs mirror. Корень на этом зеркале. примерно как тут
Предыстория
Какое-то время назад были ошибки
 
ad4: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=120175775

я поменял шлейфы, они исчезли. Потом опять появились. опять что-то со шлейфами поделал -исчезли.
пару дней назад за сутки опять появилось 2-3 такие строчки в /var/log/messages
Где-то неделю назад, всё начало очень сильно тормозить. mirror один из дисков пометил как сломанный. ( в логах были варнинги). Я что-то поделал со шлейфами, после чего zpool scrub вроде всё исправил. smart ошибок чтения не показывает, перенесённых секторов нет.
вчера комп начал что-то активно юзать диск(возноможно там торренты были, но тормоза были легко заметны, тогда как обычно даже если запущено много задач, мышка двигается ровненько).
Я решил его отрубить и разбираться утром.
Утром имеем следующее (сначала это было на 2 подключенных винтах, но если подключить каждый по отдельности будет то же самое.)
 

Verifying DMI Pool Data...........

ZFS: i/o error - all block copies unavailable
ZFS: i/o error - all block copies unavailable

FreeBSD/x86 boot
Default: tank:/boot/kernel/kernel
boot: ZFS: i/o error - all block copies unavailable

FreeBSD/x86 boot
Default: tank:/boot/kernel/kernel
boot: tank:/boot/kernel/kernelZFS: i/o error - all block copies unavailable
ZFS: i/o error - all block copies unavailable
ZFS: can't find root dsl_dir
Can't find root filesystem - giving up
ZFS: i/o error - all block copies unavailable

FreeBSD/x86 boot
Default: tank:/boot/kernel/kernel
boot: tank:/boot/kernel/kernelZFS: i/o error - all block copies unavailable

FreeBSD/x86 boot
Default: tank:/boot/kernel/kernel
boot:


оба винта могли помереть в один день? Аптайм на момент перезагрузки был месяца 2 наверно. Винтам около одного-двух лет. Или это что-то хитрое?
В инете смотрю, там вроде просто так ничего не проиходило. Такие ошибки вылезали, когда что-то переносили/обновляли и т.п.

katrin2201

оба винта могли помереть в один день?
я б голосовал за навернувшуюся из-за шлейфов фс

Phoenix

варианты решения имеются?

AlexV769

есть конечно.
1) грузишься по сети, делаешь образы дисков куда-нить на внешний носитель.
2) импортируешь пул и запускаешь scrub. После этого перепрописываешь загрузчик.

Phoenix

http://lists.freebsd.org/pipermail/freebsd-current/2009-June...
I confirmed this issue on my environment. I was analyzing it.
So I understood that gptzfsboot/loader doesn't support gang
block. As the result, gptzfsboot doesn't read gang-blocked
loader or kernel, loader doesn't read gang-blocked kernel or
modules by "ZFS: i/o error - all block copies unavailable".
I'm trying to implement gang-block support, but I done checksum
code. I'm trying to implement 'read gang block' code. But I
cannot find 'read gang block' code on zfs, yet. So now analyzing
phase....

gang-block ? Это что ?
http://www.kossoff.ru/2010/07/zfs-gang-block-detected-freebs...
У меня как раз место к концу подходило.
В сабже – мутная ошибка в бздёвой ZFS, проявляется, когда свободное место на томе подходит к концу (вообще это крайне нежелательно для ZFS данные не теряются, но бутблок херится и всё отлично работает до ребута.
Вот по этой ссылке можно прочитать много интересного по теме, но на английском языке...

http://groups.google.com/group/muc.lists.freebsd.fs/browse_t...

Phoenix

2) импортируешь пул и запускаешь scrub. После этого перепрописываешь загрузчик

А в чём проблема-то? загрузчик как пострадал? и почему?

AlexV769

Проблему ты уже, кажется, описал выше плохими шлейфами. Чтобы окончательно удостовериться, что пул находится в нормальном состоянии, нужно запустить scrub.

Phoenix

ниже там более вероятная причина нашлась с тем, что мало места на диске осталось. На это наложилось (как я понял из обсуждений gang-block) некоторый баг в загрузчике, который не позволяет читать root dsl_dir (? если он находится в этих gang-block'aх. Чего я не понимаю, зачем эти важные данные перенесли в эти gang-блоки и что это вообще такое.
На шлейфы можно списать тормоза и ворнинги.
И я не вижу, что здесь загрузчик пострадал.
 
FreeBSD/x86 boot
Default: tank:/boot/kernel/kernel
boot:

Это ведь как раз загрузчик (gptzfsboot с отдельного gpt раздела) пишет ведь.
А потом он хочет подмонтировать tank, чтобы прочитать оттуда /boot/kernel, но ему это не удаётся.

AlexV769

Это ведь как раз загрузчик (gptzfsboot с отдельного gtp раздела) пишет ведь.
Нет, это пишет /boot/loader

Phoenix

http://www.freebsd.org.ru/handbook/boot-blocks.html
 
Example 7-2. Образец экрана boot2

>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/kernel
boot:

 
Передача управления загрузчику является последним, третьим этапом в процессе начальной загрузки, а сам загрузчик находится в файловой системе, обычно как /boot/loader.

Поясни, почему это /boot/loader. Получается ФС подцепили, ведь /boot/loader в ФС находится
PS /boot/loader - это разве не меню, где можно single user выбрать? И там ещё в какой-то версии был нарисован фрибсд-демон?
http://www.freebsd.org/doc/ru/books/handbook/install/boot-loader-menu.png

Phoenix

Оказалось так:
в http://svnweb.freebsd.org/base/stable/8/sys/boot/zfs/zfsimpl... был баг
вроде вот этот баг:
 
MFC r226553 (pjd):
Always pass data size for checksum verification function, as using
physical block size declared in bp may not always be what we want.
For example in case of gang block header physical block size declared
in bp is much larger than SPA_GANGBLOCKSIZE (512 bytes) and checksum
calculation failed. This bug could lead to accessing unallocated
memory and resets/failures during boot.

собственно, нужно было обновить исходники и перезаписать gptzfsboot.
Всё случилось из-за того, что когда стало мало места, zfs стал делать gang-block вместо обычных, а т.к. изменение любых данных приводит к пересчёту чексумм и чексумм на чексумм и т.д. вплоть до самого корня, был перезаписан этот самый корень, который попал в gang-block.
освобождение места привело к тому, что корневой блок перезаписался уже в нужное место и всё заработало.
Оставить комментарий
Имя или ник:
Комментарий: