gmirror, gpart and MBR vs GPT in the Handbook

[Thomas Mueller]

from Warren Block:

> As far as I recall, MBR expects 512-byte blocks and uses 32-bit
> values. The total number works out to 2TB (2^32*512).

> Just recently, someone in the forums had an external drive, MBR
> format, but 4K blocks.  There were problems, although I don't know if
> FreeBSD was at fault.

> I have not tried MBR on a drive larger than 2TB.  I suspect it would
> be safe to use the first 2TB and ignore the rest, but that really
> ought to be verified.

There are ways (kludges) to get MBR on a drive > 2TB.

Western Digital My Book 3TB USB 3.0 hard drive was formatted with a single huge NTFS partition with some software.

In order to copy the stuff, which I've never used, I had to use the System Rescue CD.

Subsequently I migrated to GPT, deleted the huge partition, and made my own GPT partitions.

OpenBSD has a kludge with fdisk + disklabel whereby everything over 2TB goes into one (or more) disklabel partitions, but boot partition must be entirely within first 2TB.  I never tried that and don't plan to.

fdisk can't see the slice that goes past 2TB, but OpenBSD can, according to what I read on OpenBSD online documentation.

I never tried that.  OpenBSD can't access my hard drive at all for lack of support for USB 3.0 and GPT.

DragonFlyBSD latest release, 3.6.0, downloaded, bzip2 -d and dd'ed to USB sticks recognizes my hard drive partitions but can't mount any.

So all I can do with OpenBSD is download the Live USB from liveusb-openbsd.sourceforge.net, run 7z e on the download, which is 7-zipped.

7-zip (archivers/p7zip) is in FreeBSD ports, which is how I built it.

NetBSD supports GPT, but the dk wedges are not as elegant as what FreeBSD and Linux do.

NetBSD seems to be just starting with USB 3.0 support in -current.

NetBSD and OpenBSD still use preassigned device nodes with MAKEDEV such as Linux and FreeBSD had some years back.

This is actually sort of a combined response to two threads, other one being Re: kernel "mismatch" on r256420.

Tom