Date: Fri, 17 Feb 2012 07:21:45 -0800 From: Freddie Cash <fjwcash@gmail.com> To: Pete French <petefrench@ingresso.co.uk> Cc: wblock@wonkity.com, freebsd-stable@freebsd.org, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer Message-ID: <CAOjFWZ7tfO1097-wnJE5Lt8mtO2FcZhNwHBmYexxnyFi=J0eNg@mail.gmail.com> In-Reply-To: <E1RyLjZ-0009kp-GN@dilbert.ingresso.co.uk> References: <20120217030806.GA62601@icarus.home.lan> <E1RyLjZ-0009kp-GN@dilbert.ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 17, 2012 at 3:12 AM, Pete French <petefrench@ingresso.co.uk> wr= ote: >> I wasn't aware you could do that. =C2=A0I was only aware that it was the >> other way around. =C2=A0That (my) misconception seems to also be relayed >> by others such as Miroslav who said: > > Should this not be the recommended way of doing things even for MBR > disks ? I have a lot of machines booting from gmirror, but we always > do it by mirroring MBR partitions (or GPT ones). I cant see why you would > want to do it the other way round in fact. It doesnt gain you anything > does it ? The problem with mirroring partitions is that you thrash the disk during the rebuild after replacing a failed disk. And the more partitions you have, the worse it gets. If you mirror the device, then the rebuild process only has to rebuild a single "thing". If you mirror 4 partitions on a device, then there will be four simultaneous, parallel rebuild processes running, thrashing the drive heads on both devices, killing you I/O throughput and extending the length of the rebuild. And if you mix your redundancy technologies (like gmirror and zfs mirror) it gets even worse due to competing rebuild schedulers. --=20 Freddie Cash fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ7tfO1097-wnJE5Lt8mtO2FcZhNwHBmYexxnyFi=J0eNg>