Date: Sun, 7 Feb 2021 16:23:36 -0500 From: Abner Gershon <6731955@gmail.com> To: Paul Mather <paul@gromit.dlib.vt.edu>, freebsd-geom@freebsd.org Subject: Re: Making gmirror metadata cooperate with gpt metadata Message-ID: <CADC2UYexYa20wiWV2eAKvE-10F4Fi9hnh%2BEToSXEphpyLD5dMw@mail.gmail.com> In-Reply-To: <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu> References: <CADC2UYd%2B1hvOORErpHYvFMSGPeOqEd-M=oXiviqV6mRt2DZJMw@mail.gmail.com> <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Wow, thanks for opening my eyes to this. I did not realize that BSD partitions may be layered on top of a GPT partition. If I understand this correctly, you are suggesting I use fdisk to partition a GPT partition? BSD partitions are still limited to 2TB but that would be 2TB per GPT partition. My concern with gmirror on partition level is that I have seen a comment about how this may cause excessive stress on disk due to contention between various sectors for writing data during initial mirroring. In other words will gmirror update one partition at a time or will disk write head jitter back and forth writing 4k to 1st partition, 4k to 2nd partition, 4k to 3rd partition, etc. I have been resisting ZFS because of inefficiencies of COW for updating database files ( as opposed to updating one block of existing file ). I plan to set up a server with some UFS gmirror and some ZFS storage and do some comparisons. Will post back my results when I do. Most related posts I have seen suggest ZFS is the way of the now/future but then again I am driving a 1988 Ford ranger with manual transmission. Regards, Abner On Sun, Feb 7, 2021 at 3:28 PM Paul Mather <paul@gromit.dlib.vt.edu> wrote: > 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. > > > > The reason this is currently impossible is due to GPT and gmirror both > > trying to store metadata in the last disk sector. > > > > MBR does not allow for partitioning of disk greater 2T. > > > > 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, i= t > 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 lead= s > to loss of mirror synchronisation. In a whole-disk mirror, you are alway= s > going to have to resynchronise the whole disk, whereas with partition-lev= el > 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 - s= rc - 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. > > > > What would be the ramifications of altering gmirror to store metadata o= n > > 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 t= he > 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 ou= t > 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?CADC2UYexYa20wiWV2eAKvE-10F4Fi9hnh%2BEToSXEphpyLD5dMw>