Hi. Someone currently reported a 'ss == NULL' panic in space_map.c/space_map_add() on FreeBSD's version of ZFS.
I found that this problem was previously reported on Solaris and is already fixed. I verified it and FreeBSD's version have this fix in place... http://src.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/uts/common/fs/zfs/space_map.c?r2=3761&r1=3713 I'd really like to help this guy get his data back, so please point me into right direction. We have a crash dump of the panic, BTW. It happened after a spontaneous reboot. Now, the system panics on 'zpool import' immediately. He already tried two things: 1. Importing the pool with 'zpool import -o ro backup'. No luck, it crashes. 2. Importing the pool without mounting file systems (I sent him a patch to zpool, to not mount file systems automatically on pool import). I hoped that maybe only one or more file systems are corrupted, but no, it panics immediately as well. It's the biggest storage machine in there, so there is no way to backup raw disks before starting more experiments, that's why I'm writting here. I've two ideas: 1. Because it happend on system crash or something, we can expect that this is caused by the last change. If so, we could try corrupting most recent uberblock, so ZFS will pick up previous uberblock. 2. Instead of pancing in space_map_add(), we could try to space_map_remove() the offensive entry, eg: - VERIFY(ss == NULL); + if (ss != NULL) { + space_map_remove(sm, ss->ss_start, ss->ss_end); + goto again; + } Both of those ideas can make things worse, so I want to know what damage can be done using those method, or even better, what else (safer) we can try? -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
pgp6Xm9y44G1x.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss