Date: Thu, 16 Jul 2009 10:28:40 +0200 From: Henri Hennebert <hlh@restart.be> To: Peter Schuller <peter.schuller@infidyne.com> Cc: Randy Bush <randy@psg.com>, freebsd-current@freebsd.org, Freddie Cash <fjwcash@gmail.com> Subject: Re: ZFS pool corrupted on upgrade of -current (probably sata renaming) Message-ID: <4A5EE4B8.9050000@restart.be> In-Reply-To: <20090715200342.GA89750@hyperion.scode.org> References: <alpine.BSF.2.00.0907132009040.2027@teapot.cbhnet> <alpine.BSF.2.00.0907142318520.2686@teapot.cbhnet> <b269bc570907141550u6854bc8eh6ea73fe9bd3e788a@mail.gmail.com> <m21voi1ufz.wl%randy@psg.com> <b269bc570907150922l3ded8a76id12ea72801abb3c7@mail.gmail.com> <20090715200342.GA89750@hyperion.scode.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Schuller wrote: >> Yep. It's as simple as: >> >> * label all the drives using glabel, while they're still attached to the >> pool >> * use "zpool replace pool ad4 label/disk01" to replace 1 drive >> * wait for it to resilver >> * use "zpool replace pool ad6 label/disk02" to replace the next drive >> * repeat the resilver and replace until all the devices are replaced > > While I can see this working "most of the time" - is there any reason > to believe it is guaranteed to? glabel keeps meta data at the end of > the device; is it guaranteed that ZFS is not using that part of the > device actively? (For example by having a policy to reserve some > amount at the end.) > Indeed, I find this paper really interesting: http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf Henri
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A5EE4B8.9050000>