Date: Fri, 21 Mar 2014 14:15:45 +0600 From: "Eugene M. Zheganin" <emz@norma.perm.ru> To: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: crash on zpool import - help get data back Message-ID: <532BF531.1050400@norma.perm.ru> In-Reply-To: <532BEABC.5050808@norma.perm.ru> References: <532BEABC.5050808@norma.perm.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. On 21.03.2014 13:31, Eugene M. Zheganin wrote: > Hi. > > After some time using zfs on a 10.x server (and a couple of panics) I'm > now getting the reproducible and repeatable panic on any operations > involving particular pool. I managed to boot from USB stick, import only > healthy pools and substitite the server's zpool.cache file with one > referencing only healthy pools. Now I'm able to boot, but when I try to > import the remaining pool I'm getting the panic (attached below). Now > questions: > > - do I understand correctly that "#7 0xffffffff8188e076 in > vdev_readable (vd=0x0)" means vd is NULL, and this is triggering the panic ? > - I saw a similar (but not identical) panic in > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013513.html , > - are there any possible tricks that could help me getting my data ? After some thinking (speeded up with the superiors running in circles) I realized that the root cause is the same and I can apply the tricks mentioned above. However, the question remains - how could this happen, because the main difference between me and original thread author is that I don't have memory errors. Furthermore, may be this technique can be applied to the FreeBSD zfs code, for example switching affected vdevs into the DEGRADED state, like solaris fmadm does when it's getting errors on a disk, thus signalling that the pool actually isn't healthy anymore ? However, I am not a programmer of any kind, so this is just a thought based on a fact that two individuals independently stepped on same issue. Thanks. Eugene.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?532BF531.1050400>