Date: Mon, 27 Dec 2010 16:30:30 +1100 From: Jean-Yves Avenard <jyavenard@gmail.com> To: jhell <jhell@dataix.net> Cc: freebsd-stable@freebsd.org Subject: Re: New ZFSv28 patchset for 8-STABLE: Kernel Panic Message-ID: <AANLkTikUPU94fisHKBBu%2BX1TKS8LKN1GWAYRZAFX1eJq@mail.gmail.com> In-Reply-To: <4D181E51.30401@DataIX.net> References: <AANLkTinxvU_QuAd6SG1hig7-YeC8tCdwAmwgL1AXfHNN@mail.gmail.com> <AANLkTimNv1%2BfL2KUrxLoTO2oQ=ziOO6raWT5TMZJkH4f@mail.gmail.com> <4D181E51.30401@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi On 27 December 2010 16:04, jhell <jhell@dataix.net> wrote: > > Before anything else can you: (in FreeBSD) > > 1) Set vfs.zfs.recover=1 at the loader prompt (OK set vfs.zfs.recover=1) > 2) Boot into single user mode without opensolaris.ko and zfs.ko loaded > 3) ( mount -w / ) to make sure you can remove and also write new > zpool.cache as needed. > 3) Remove /boot/zfs/zpool.cache > 4) kldload both zfs and opensolaris i.e. ( kldload zfs ) should do the trick > 5) verify that vfs.zfs.recover=1 is set then ( zpool import pool ) > 6) Give it a little bit monitor activity using Ctrl+T to see activity. > > You should have your pool back to a working condition after this. The > reason why oi_127 can't work with your pool is because it cannot see > FreeBSD generic labels. The only way to work around this for oi_127 > would be to either point it directly at the replacing device or to use > actual slices or partitions for your slogs and other such devices. > > Use adaNsN or gpt or gptid for working with your pool if you plan on > using other OS's for recovery effects. > Hi.. Thank you for your response, I will keep it safely should it ever occur again. Let me explain why I used labels.. It all started when I was trying to solve some serious performance issue when running with zfs http://forums.freebsd.org/showthread.php?t=20476 One of the step in trying to trouble shoot the latency problem, was to use AHCI ; I had always thought that activating AHCI in the bios was sufficient to get it going on FreeBSD, turned out that was the case and that I needed to load ahci.ko as well. After doing so, my system wouldn't boot anymore as it was trying to be /dev/ad0 which didn't exist anymore and was now names /dev/ata0. So I used a label to the boot disk to ensure that I will never encounter that problem ever again. In the same mindset, I used labels for the cache and log device I later added to the pool... I have to say however, that zfs had no issue using the labels until I tried to remove it. I had rebooted several times without having any problems. zpool status never hanged It all started to play up when I ran the command: zpool remove pool log label/zil zpool never ever came out from running that command (I let it run for a good 30 minutes, during which I was fearing the worse, and once I rebooted and nothing ever worked, suicide looked like an appealing alternative) It is very disappointing however that because the pool is in a non-working state, none of the command available to troubleshoot the problem would actually work (which I'm guessing is related to zpool looking for a device name that it can never find being a label) I also can't explain why FreeBSD would kernel panic when it was finally in a state of being able to do an import. I have to say unfortunately, that if I hadn't had OpenIndiana, I would probably still by crying underneath my desk right now... Thanks again for your email, I have no doubt that this would have worked but in my situation, I got your answer in just 2 hours, which is better than any paid support could provide ! Jean-Yves PS: saving my 5MB files over the network , went from 40-55s with v15 to a constant 16s with v28... I can't test with ZIL completely disabled , it seems that vfs.zfs.zil_disable has been removed, and so did vfs.zfs.write_limit_override
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikUPU94fisHKBBu%2BX1TKS8LKN1GWAYRZAFX1eJq>