Date: Mon, 17 May 2010 03:27:52 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen <staalebk@ifi.uio.no> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: Bad hardware + zfs = panic Message-ID: <20100517012752.GA3943@putsch.kolbu.ws> In-Reply-To: <20100512110803.GF1703@garage.freebsd.pl> References: <20100506012217.GA41806@putsch.kolbu.ws> <20100512102156.GE1703@garage.freebsd.pl> <20100512110803.GF1703@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2010-05-12 at 13:08, Pawel Jakub Dawidek wrote: > On Wed, May 12, 2010 at 12:21:56PM +0200, Pawel Jakub Dawidek wrote: <removed panic> > > Well, I don't think it should be possible for vdev to be NULL. > > But if you still have this panic, can you try this patch: > > > > http://people.freebsd.org/~pjd/patches/vdev_mirror.c.patch Yeah, it shouldn't be possible, but I had something in my system that corrupted data in memory, and that can lead to all sorts of problems. I'm not blaming ZFS for not handling 'impossible' situations, but this seemed like something that could be avoided. I'm actually impressed with how well ZFS handled it, my UFS root-fs went ballistic a few times. > It looks like: > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6435666 > > The work-around is to remove /boot/zfs/zpool.cache and import the pool > again. Fortunately I found out which file was problematic, and after removing it and recreating it, I've had no more panics. I'm not sure if the tip on that page would have solved the problem, because zpool.cache is removed on my system when exporting the pool. Thanks for the help tho, everything looks to be working now :) -- Ståle Kristoffersen staalebk@ifi.uio.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100517012752.GA3943>