Date: Wed, 30 Aug 2017 18:59:54 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Frank Leonhardt <frank2@fjl.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: help creating new gmirror > 2TB Message-ID: <alpine.BSF.2.21.1708301856210.93591@wonkity.com> In-Reply-To: <26f5e88e-1ea7-6332-ca5e-f055cfbdd280@fjl.co.uk> References: <CAFsnNZLeuLYEJVozsoSvDtvgfMf4UueJhm37waOQ5_kyxs-rhg@mail.gmail.com> <26f5e88e-1ea7-6332-ca5e-f055cfbdd280@fjl.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Aug 2017, Frank Leonhardt wrote: > On 29/08/2017 21:12, William Dudley wrote: >> Hi, >> >> I want to create a simple mirror > 2TB on a FreeBSD 10.3 system. >> >> I have 2 identical 4TB disks. >> >> The examples in freebsd handbook "geom-mirror" pages show creation of a 2TB >> mirror using >> MBR partitioning, and that has an upper limit of 2TB. >> >> Some documentation says not to use GPT partitioning with gmirror because >> both store their information in the last sector on the disk. >> >> I'm not expert enough to be able to solve this myself. >> >> How do I create a gmirror of 4TB size? >> >> I want to partition it into 4 slices after I create it, but think I can use >> gpart to do that. >> >> Note: I'm not interested in using zfs unless there's no way to do this with >> gmirror. >> I read too many zfs failure stories on this mailing list to be comfortable >> with zfs. > > I still get a bit worried about this, but I'm 99.9% sure you'll be okay with > MBR assuming it's an AFD (4K sector drive). The bodge/workaround works. If > it's SAS instead of SATA, all bets are off. > > Although I use ZFS a lot, I still prefer geom mirror for twin-disk systems. I > feel a lot more comfortable booting from it in the event of a failure. ZFS > has its good points, but so does UFS. > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.1708301856210.93591>