середу, 5 травня 2010 р.

Пляски с ZFS

Из цитат на #freebsd@RusNet:
zfs = оно то вроде работает, но если/когда она развалится, то что с ней делать не понятно вообще (c) levsha.
fsck не нужен, потому что не поможет (c) kib
"Вот наконец настал тот час", и zfs у меня поломался.
На сервере отвалился один диск (не из того пула, который потом сломался, а из другого). Но это отваливание как-то серьезно переклинило контроллер (да, adaptec говно), и посыпалась куча таймаутов от контроллера.
Полностью выключил сервер, подождал некоторое время и включил. В результате после загрузки получил панику. Попробовал удалить /boot/zfs/zpool.cache . В результате пулы перестали автоматически подключаться (совершенно справедливо) и стали видны по zpool import. При этом нужный пул стал помечен UNAVAILABLE, хотя он состял из одного raidz из 6 дисков, причем и raidz и все 6 дисков отображались как ONLINE.
Для ковыряний попробовал использовать zdb. Он при попытке запуска на пул падал по segmentation fault. Это оказалось плюсом: zdb использует тот же код, что и zfs.ko, но на user level, что, впервых, дает core dump вместо panic, во вторых позовляет использовать обычный gdb.
Ковыряния кода с помощью gdb показали, что где-то в душе вызывается zio_vdev_io_start() с zio->io_vd == NULL . Где и почему это происходит я не нашел. При этом zio_vdev_io_start считает что может справиться с такой ситуацией:
if (vd == NULL) {
if (!(zio->io_flags & ZIO_FLAG_CONFIG_WRITER))
spa_config_enter(spa, SCL_ZIO, zio, RW_READER);

/*
* The mirror_ops handle multiple DVAs in a single BP.
*/
return (vdev_mirror_ops.vdev_op_io_start(zio));
}
Вот только vdev_op_io_start совершенно не приспособлен до такой ситуаци: он в конце концов вызывает вот такую функцию:
boolean_t
vdev_is_dead(vdev_t *vd)
{
return (vd->vdev_state < VDEV_STATE_DEGRADED); }





за что сразу получает по голове (или sigsgev в случае zdb, или panic в случае zfs.ko).
Простенький патч вида
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c
===================================================================
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c (revision 207555)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c (working copy)
@@ -1845,6 +1845,10 @@
boolean_t
vdev_is_dead(vdev_t *vd)
{
+ if( vd == NULL ){
+ printf("XXX: Attemt to call vdev_is_dead for NULL vd\n");
+ return 1;
+ }
return (vd->vdev_state < VDEV_STATE_DEGRADED); }





панику исправил, вот только к работоспособности это не привело: теперь операции, которые проходили по этому коду, просто бесконечно долго ждали завершения io.
Дальнейшие ковыряния в направлении "а почему же этот пул помечается как UNAVALIABLE и что с этим можно сделать?" дали результатом такое: UNAVAILABLE пул считается тогда, когда zfs решил что некоторые устройства из пула недоступны, но не может определить какие именно. Для того, чтобы было возможно определить такую ситуацию, zfs записывает в каждый uberblock (The uberblock is similar to the superblock in UFS (c) ZFS On-Disk Specification) контрольную сумму идентификаторов всех устройств, входящих в пул. Поизучавши http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf была накалякана вот такая приблуда:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/uio.h>
#include <unistd.h>
#include <errno.h>

#define UBERBLOCK_MAGIC 0x00bab10c /* oo-ba-bloc! */
#define UBERBLOCK_SHIFT 10 /* up to 1K */

typedef struct dva {
uint64_t dva_word[2];
} dva_t;

typedef struct zio_cksum {
uint64_t zc_word[4];
} zio_cksum_t;

typedef struct blkptr {
dva_t blk_dva[3]; /* 128-bit Data Virtual Address */
uint64_t blk_prop; /* size, compression, type, etc */
uint64_t blk_pad[3]; /* Extra space for the future */
uint64_t blk_birth; /* transaction group at birth */
uint64_t blk_fill; /* fill count */
zio_cksum_t blk_cksum; /* 256-bit checksum */
} blkptr_t;

typedef struct uberblock {
uint64_t ub_magic; /* UBERBLOCK_MAGIC */
uint64_t ub_version; /* SPA_VERSION */
uint64_t ub_txg; /* txg of last sync */
uint64_t ub_guid_sum; /* sum of all vdev guids */
uint64_t ub_timestamp; /* UTC time of last sync */
blkptr_t ub_rootbp; /* MOS objset_phys_t */
} uberblock_t;

int main(int argc, char* argv[]){

uberblock_t* ub = malloc(sizeof ub);
int res;

while( (res = read(0, ub, sizeof *ub) ) > 0 ){
if( ub->ub_magic != 0x00bab10c )
continue;
printf("ub_magic=%jx, ub_version=%ju, ub_txg=%ju, ub_guid_sum=%ju, ub_timestamp=%ju\n",
ub->ub_magic, ub->ub_version, ub->ub_txg, ub->ub_guid_sum, ub->ub_timestamp);

}
if( res < 0 ){ fprintf(stderr, "read(): %d\n", errno); } free(ub); return 0; }





На stdin пограммы были скормлены dd if=(тут перебираем все диски) bs=128k count=1 skip=(тут перебираем 1,3, последний и предпоследний блок на диске) . С блоками так потому, что zfs записывает на каждый диск 4 vdev label: две в начале и две в конце, и каждая vdev label заниает 256KBytes, из которых вторая половина это uberblocks array.
В моём случае было обнаружено что на нулевом диске несколько последних uberblock-ов содержат другую ub_guid_sum. Поэтому этот диск был просто вытянут, после чего zfs спокойно распознала этот пул.
Вот такое вот шаманство этот zfs...

2 коментарі:

234131 сказав...

Дякую. Як-раз думав наступні три таза підняти на zfs :-)

levsha сказав...

І яке рішення?
А то насправді після цієї ситуації мені важко сказати як змінилось моє відношення до zfs. Можливо навіть покращилось: вони таки зберегла дані. Підозрюю що у випадку ufs я або отримав би кучу файлів в lost+found, або просто тихо й непомітно десь би запоровся вміст якогось файлу