Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Nov 2009 21:00:51 GMT
From:      Gerrit Kühn <gerrit@pmp.uni-hannover.de>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/140433: ZFS panics kernel while replaying ZIL after crash
Message-ID:  <200911092100.nA9L0p3m056407@www.freebsd.org>
Resent-Message-ID: <200911092110.nA9LA1J6002159@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         140433
>Category:       kern
>Synopsis:       ZFS panics kernel while replaying ZIL after crash
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Nov 09 21:10:00 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Gerrit Kühn
>Release:        FreeBSD 8.0-RC2
>Organization:
AEI
>Environment:
FreeBSD 8.0-RC2 on AMD64
>Description:
After a crash (by starting powerd, if that matters) zpool comes back fine, but panics when trying to mount one particular fs inside the pool. All other fs are fine, also the properties of the broken fs can be accessed. A picture of the crash and a trace using ddb can be found here: <http://www.pmp.uni-hannover.de/test/Mitarbeiter/g_kuehn/data/zfs-panic2.jpg>;
It looks like there is a problem replaying the ZIL.

Some more info about the hardware and setup:
These are 4x2.5" 400GB drives (WD4000BEVT) in a RAID-Z1 setup on a
Supermicro AOC-USAS-L8i controller (LSI chip, mpt driver) in a VIA VB8001
board (powered by a Via Nano 1.6GHz) with 4GB of memory. System runs off a UFS-FS CF-card and uses ZFS for data, /var and /tmp.
>How-To-Repeat:
I had a similar issue before when the system had crashed once for a different reason. So the situation is probably easily triggered here. I have not yet tried to re-do the pool and trigger it again to be able to give feedback on the problem at hand.
>Fix:
Unknown to me. However, imho zfs should not panic the kernel, even if there is a corrupted zil. If these cases cannot be avoided 100%, something like an --disgard-zil switch would be very helpful from my (user's) point of view.

>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200911092100.nA9L0p3m056407>