Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Feb 2021 15:28:58 -0500
From:      Paul Mather <paul@gromit.dlib.vt.edu>
To:        Abner Gershon <6731955@gmail.com>
Cc:        pjd@freebsd.org, freebsd-geom@freebsd.org
Subject:   Re: Making gmirror metadata cooperate with gpt metadata
Message-ID:  <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu>
In-Reply-To: <CADC2UYd%2B1hvOORErpHYvFMSGPeOqEd-M=oXiviqV6mRt2DZJMw@mail.gmail.com>
References:  <CADC2UYd%2B1hvOORErpHYvFMSGPeOqEd-M=oXiviqV6mRt2DZJMw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 7, 2021, at 8:50 AM, Abner Gershon <6731955@gmail.com> wrote:

> Disclaimer, I am not a programmer but have tinkered with shell and =
perl
> scripts. Having said that, I think many would appreciate the option of
> using gmirror with disks larger than 2T.
>=20
> The reason this is currently impossible is due to GPT and gmirror both
> trying to store metadata in the last disk sector.
>=20
> MBR does not allow for partitioning of disk greater 2T.
>=20
> Workaround to gmirror partitions rather than whole disk is less than =
ideal.


Personally, I don't find mirroring individual partitions "less than =
ideal" or at least onerous enough to enforce "whole-disk" semantics.  =
For one, it lets you use different balance algorithms for different =
partitions, e.g., "prefer" on mirrored swap (so crash dumps work without =
extra effort) and other balance algorithms for other file systems.  For =
another, you might potentially have to rebuild less data, depending on =
the failure that leads to loss of mirror synchronisation.  In a =
whole-disk mirror, you are always going to have to resynchronise the =
whole disk, whereas with partition-level mirrors you might be lucky and =
have to resynchronise only a single partition.  Also, you could turn =
automatic resynchronisation off where it's not needed, e.g., for =
auto-encrypted swap partitions.

Gmirror's naive resilvering is also why I prefer to use ZFS for =
mirroring: it resilvers (resynchronises) only actual data, and so is =
much faster for pools that are emptier.

(I only use gmirror for swap nowadays and use ZFS for everything else.)


> Lines 254-293 of geom_mirror.c =C2=AB mirror =C2=AB geom =C2=AB lib - =
src - FreeBSD source
> tree
> =
<https://cgit.freebsd.org/src/tree/lib/geom/mirror/geom_mirror.c?h=3Drelen=
g/13.0>
> relate
> to clearing and storing metadata on last sector of disk.
>=20
> What would be the ramifications of altering gmirror to store metadata =
on
> the 2nd to last sector?


This is basically what it ends up doing already.  You make a GPT =
covering the whole disk and the GPT uses the last sector for the backup. =
 You then make a gmirror inside this GPT container and it uses the last =
sector of the container (second-to-last sector of the drive) for its =
gmirror stored metadata.

Also, couldn't you achieve your end using BSD partitions, or are they =
disallowed inside GPT partitions?  (I.e., create a GPT covering the =
whole disk; create a GPT partition covering the entire GPT; create a =
gmirror out of that; create a BSD partition on the gmirror for your file =
systems.)

Cheers,

Paul.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7>