Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jun 2012 15:03:41 -0500
From:      Mark Felder <feld@feld.me>
To:        freebsd-hackers@freebsd.org
Subject:   Re: [CFC/CFT] large changes in the loader(8) code
Message-ID:  <op.wgkvcfnu34t2sn@tech304>
In-Reply-To: <201206261337.11741.jhb@freebsd.org>
References:  <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Jun 2012 12:37:11 -0500, John Baldwin <jhb@freebsd.org> wrote:

> I'm
> hesitant to encourage the use of this as I do think putting GPT inside  
> of a
> gmirror violates the GPT spec.

I personally think this use case is a bit ... odd, anyway.

I have only request to those that manage GPT/GEOM/etc -- as I'm used to  
doing multiple mdadm RAID components on Linux for maximum flexibility,  
using gmirror upon multiple GPT partitions upon the same physical device  
is OK with me. My only complaint is that recovery is very, very stupid. We  
should by default detect and only rebuild ONE gmirror device at a time on  
the same physical provider. You get nothing but a smokin' angry head if  
you allow multiple to rebuild at the same time because it's fighting over  
sequential writes all the way across the platters. It would also be nice  
if gmirror rebuild could also be detected by fsck and fsck could either  
hold off or gmirror could be paused until a consistent filesystem state  
exists. It's probably best for the background fsck to go first so you can  
get the system up and running, but then when it's finished gmirror should  
continue.

Otherwise I have no issues with gmirror -- it does exactly the job I need  
it to.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.wgkvcfnu34t2sn>