Date: Tue, 14 Jul 2009 23:57:54 +0100 (BST) From: Chris Hedley <freebsd-current@chrishedley.com> To: Freddie Cash <fjwcash@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: ZFS pool corrupted on upgrade of -current (probably sata renaming) Message-ID: <alpine.BSF.2.00.0907142354180.2686@teapot.cbhnet> In-Reply-To: <b269bc570907141550u6854bc8eh6ea73fe9bd3e788a@mail.gmail.com> References: <alpine.BSF.2.00.0907132009040.2027@teapot.cbhnet> <alpine.BSF.2.00.0907142318520.2686@teapot.cbhnet> <b269bc570907141550u6854bc8eh6ea73fe9bd3e788a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Jul 2009, Freddie Cash wrote: > While I don't have any insight into how to repair this issue you've run into > (at least not off-hand), one way to mitigate/prevent this from happening is > to use glabel to label the drives, and then use the labels to create the > zpool. That way, it doesn't matter where the physical devices are located > in the system, nor what the physical device nodes are called, as zpool just > looks for the label, and GEOM handles all the heavy lifting/translating for > you. > > # glabel label disk01 /dev/ad4 > # glabel label disk02 /dev/ad6 > # glabel label disk03 /dev/ad8 > # zpool create pool raidz1 label/disk01 label/disk02 label/disk03 > > After that, you can shuffle the drives around in the system, and the pool > will continue to work correctly. 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. Cheers, Chris.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0907142354180.2686>