Date: Tue, 2 Feb 2010 17:12:38 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= <gerrit@pmp.uni-hannover.de> To: Gerrit =?ISO-8859-1?Q?K=FChn?= <gerrit@pmp.uni-hannover.de> Cc: freebsd-fs@freebsd.org Subject: Re: trace for zfs panic mounting fs after crash with RC2 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> <ed91d4a80911100817k5715ae0fnbf53c6986722964f@mail.gmail.com> <20091112092630.e7cd6836.gerrit@pmp.uni-hannover.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Nov 2009 09:26:30 +0100 Gerrit K=FChn <gerrit@pmp.uni-hannover.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100202171238.7694c19e.gerrit>