From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 16:12:42 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A46ED106566C for ; Tue, 2 Feb 2010 16:12:42 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2C10A8FC13 for ; Tue, 2 Feb 2010 16:12:41 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o12GCcZE003944; Tue, 2 Feb 2010 17:12:40 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8D5BB24; Tue, 2 Feb 2010 17:12:38 +0100 (CET) Date: Tue, 2 Feb 2010 17:12:38 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Gerrit =?ISO-8859-1?Q?K=FChn?= Message-Id: <20100202171238.7694c19e.gerrit@pmp.uni-hannover.de> In-Reply-To: <20091112092630.e7cd6836.gerrit@pmp.uni-hannover.de> References: <20091106094734.4b056899.gerrit@pmp.uni-hannover.de> <4AF4123A.4080301@andric.com> <20091106231440.4f0f2cbb.gerrit@pmp.uni-hannover.de> <4AF4AAFF.2080104@jrv.org> <20091109101255.e81774e4.gerrit@pmp.uni-hannover.de> <4AF98032.9050808@bellanet.org> <20091110164622.6bc7aca1.gerrit@pmp.uni-hannover.de> <20091112092630.e7cd6836.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.2.160320 Cc: freebsd-fs@freebsd.org Subject: Re: trace for zfs panic mounting fs after crash with RC2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 16:12:42 -0000 On Thu, 12 Nov 2009 09:26:30 +0100 Gerrit K=FChn wrote about Re: trace for zfs panic mounting fs after crash with RC2: AB> Perhaps some of the links on the following post on zfs-discuss may AB> help: AB> http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg26704.html GK> Interesting stuff, thanks. GK> At a first glance I do not see an easy way to roll back my pool to a GK> slightly previous (consistent) state, but all the posts state that it GK> is possible. I guess I have to dive into this a bit deeper. "zpool GK> clear -F" definitely would be the easier-to-use solution. AB> Another option would be to boot from OpenSolaris LiveCD that AB> contains latest zfs changes, import your pool there, fix, export AB> and then re-import it on FreeBSD. Make sure you don't upgrade your AB> pool while running OpenSolaris. GK> Uh, yes, not really an option in this case, I guess. Unless I buy an GK> additional external CD drive and stuff. But thanks for the hint, GK> anyway. I will have a look around how difficult it is to get recent GK> OpenSolaris on a USB stick... Just to get this documented: I was not able to get OSL on a USB medium since you need a special tool for putting an image on a stick that rungs under Solaris -> checken-egg-problem. I borrowed an external usb cd drive and downloaded the latest osl (131) from grunix. grub came up fine, selecting Solaris led to some dots on the screen (obviously the kernel being loaded), then there was a block screen with a blinking cursor, after some time the system rebooted. I added -v to boot the kernel and got as far as Sun's Copyright, then it hang again, rebooting some time later. I added -k -d to activate the kernel debugger and managed to follow what it is actually doing... well, after coming up with the cpu, OSL tried to activate hyperthreading, which is not supported by the cpu, and bang... After knowing what is going wrong, it was relatively easy to find the problem on the web. My system has a VIA NANO processor, which supports 64bit, but no HT. OSL obviously supposes that any cpu not being and AMD and having 64bit can support ht, too. The bug is there as long as the nano processor exists (first reports in 2008), but obviously unfixed. :-( I changed grub's boot line to load the 32bit OSL instead. This comes up fine. I could only boot textmode or vesa, otherwise the system does not recognize my onboard graphics. After googleing the default login and default root account (why don't they display this on the login prompt?) I could login, hat my zpool recognized and could import/export it without any hassle. After this the pool worked fine in FreeBSD again. One thing I noted is that the first disk changed its name from label/disk-0 back to da0 in the pool, although there still is a glabel on it. I don't know why this happened nor how to get back do use the glabel on this disk, but it seems to work anyway. The whole issue took me several attempts and at least 4 hours of work altogether (that's why I want to document it here to save other people this time :-). I would really love to see these fixing features imported in FreeBSD as soon as possible. BTW: I did not even have to specify the -F option when importing the pool. So maybe OSL is also more clever about what to do with inconsistent ZIL states... cu Gerrit