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: /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa 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/)
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 then. -- Alex 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: > /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa > 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080719/f0e6f39e/attachment.pgp
On Sat, Jul 19, 2008 at 10:51:21AM +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: > /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa > 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?Can you try this patch? http://people.freebsd.org/~pjd/patches/space_map.c.patch -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080719/befab733/attachment.pgp