help creating new gmirror > 2TB
Frank Leonhardt
frank2 at fjl.co.uk
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