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
