Date: Wed, 15 Jul 2009 03:07:07 +0400 From: Kamigishi Rei <spambox@haruhiism.net> To: Chris Hedley <freebsd-current@chrishedley.com> Cc: freebsd-current@freebsd.org, Freddie Cash <fjwcash@gmail.com> Subject: Re: ZFS pool corrupted on upgrade of -current (probably sata renaming) Message-ID: <4A5D0F9B.1010900@haruhiism.net> In-Reply-To: <alpine.BSF.2.00.0907142354180.2686@teapot.cbhnet> References: <alpine.BSF.2.00.0907132009040.2027@teapot.cbhnet> <alpine.BSF.2.00.0907142318520.2686@teapot.cbhnet> <b269bc570907141550u6854bc8eh6ea73fe9bd3e788a@mail.gmail.com> <alpine.BSF.2.00.0907142354180.2686@teapot.cbhnet>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Hedley wrote: > Thanks - that was just what I was looking for! That'll save me an > awful lot of hassle in future, especially as I'm eyeing up the CAM > integration patch. In the meantime I'm successfully but slowly > retrieving my data, I'll just have to be patient, but it's reassuring > that I can build a new ZFS array with confidence. There was another step you could take to recover your array safely. Right after that upgrade after witnessing the problem, boot back into kernel.old in single user mode and doing /etc/rc.d/zfs start zpool export poolname and then rebooting into normal kernel in single user mode again and doing /etc/rc.d/zfs start zpool import poolname That's how I solved it when I moved from adXX to adaXX device names. Actually, just to be sure, I export pools for every update that touches ata/ahci modules. -- Kamigishi Rei KREI-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A5D0F9B.1010900>