This will give you some insight about the pains of trying to use disklabel on larger disks. However If you add another drive later, I see no reason why it couldn't be gpt, and the current one mbr.
----- Original Message ----- From: Swift Griggs <swiftgri...@gmail.com> To: netbsd-users@netbsd.org Sent: Monday, February 8, 2016 5:02 PM Subject: Re: GPT vs BSD-label On Mon, 8 Feb 2016, John Nemeth wrote: > Standard BSD disklabels have the same limitation as MBRs as they use > 32-bit numbers for partition start and size. I take it that there is more to it than that... ? I'm sure I'm over-simplifying, but simply changing the long to a int64_t I suppose has greater impact and implications for other tools and code that read disklabels, right ? I'm sure you see where I'm going. I'm just basically thinking that I have no need for GPT partition tables on systems that will never run anything but NetBSD. The only concern is losing capacity or the ability to get at future capacity. Your point about 6TB disks is spot-on. However, disk slices are fundemental to BSD and it's tools, so I figured I do an experiment with "nothing but what I need". I find GPT's tail-backup annoying anyway. Thanks, Swift
