help creating new gmirror > 2TB

Frank Leonhardt frank2 at
Thu Aug 31 14:26:25 UTC 2017

On 31/08/2017 01:59, Warren Block wrote:
> On Wed, 30 Aug 2017, Frank Leonhardt wrote: 

>> Trying to get geom mirror to work with GPT as it stands just leads to 
>> pain. I've taken a look at the code with a view to fixing this is no 
>> one else does, but UFS is so un-cool in most circles and I don't 
>> fancy doing it alone in case I zap someone's data. it doesn't look 
>> that tricky to move the metadata somewhere else, and by checking for 
>> a GPT you can select between the old/new block. It's unexpected 
>> interactions I'm worried about.
> At some point in the last couple of years, hrs@ produced a working 
> patch which did something like that, although I don't remember the 
> details. It moved either the GPT backup table or the gmirror 
> metadata.  It was turned down as breaking standards.

I remember something like this too - if you turn it up please point me 
at it!

I have a feeling that it moved the GPT backup for some reason. Moving 
the mirror metadata would make more sense, but I assume this was tricky 
for some reason.

I think there's a good argument for a geom mirror2, designed to work 
with GPT. IME ZFS isn't the universal answer to everything thanks to 
CoW, random-access R/W files and fragmentation. Until the fragmentation 
issue can be addressed (e.g. with a defragger) databases and VM images 
are going to run badly.

Another answer would be for a FS to access it at vdev level (i.e. just 
use the volume manager aspect). At the moment it's a CoW dataset or a 
CoW dataset. I'd assumed Oracle would have addressed this, given their 
interest in databases.

Regards, Frank.

More information about the freebsd-questions mailing list