Panic on ZFS startup after crash
alex at trull.org
Sat Jul 19 09:17:22 UTC 2008
I've tried neither of these in your particular case, but they might be
worth a try:
Just a suggestion, but try specify vfs.zfs.zil_disable=1 or as a kernel
variable in the boot cli.
You may want to try export and import the pool and see how it likes it
On Sat, 2008-07-19 at 10:51 +0200, Daniel Eriksson wrote:
> I have a large ZFS pool that seems to be partially corrupt, causing a
> panic on ZFS startup. This is on a RELENG_7_0 machine.
> This is what happens when I try to start ZFS (written down by hand):
> ZFS: WARNING: can't process intent log for tank02/home
> ZFS: WARNING: can't process intent log for tank02
> panic: solaris assert: dmu_read(os, smo->smo_object, offset, size,
> entry_map) == 0 (0x5 == 0x0), file:
> ce_map.c, line: 341
> The pool sits on top of a geli-encrypted hardware raid-array (Highpoint
> RocketRAID 2340, 8 x 500GB in RAID-5 config). Unfortunately the array
> broke (2 drives disconnected) due to a bad PSU, and this eventually
> crashed the box. When I restarted the box the above message showed up as
> soon as I started ZFS.
> It is my understanding that the intent log is emptied on clean shutdown,
> and if it is not empty during startup ZFS tries to "replay" the
> transactions recorded in it. I assume the initial crash left the intent
> log in an inconsistent state and that ZFS panics on startup due to badly
> formatted data in the intent log.
> Is there any way I can recover this pool?
> Daniel Eriksson (http://www.toomuchdata.com/)
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080719/f0e6f39e/attachment.pgp
More information about the freebsd-stable