NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: GPT vs BSD-label



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.  

https://wiki.netbsd.org/users/mlelstv/using-large-disks/




----- Original Message -----
From: Darren <darren780%yahoo.com@localhost>
To: Swift Griggs <swiftgriggs%gmail.com@localhost>; NetBSD User Maillist <netbsd-users%netbsd.org@localhost>
Sent: Monday, February 8, 2016 5:30 PM
Subject: Re: GPT vs BSD-label

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 <swiftgriggs%gmail.com@localhost>
To: netbsd-users%netbsd.org@localhost
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


Home | Main Index | Thread Index | Old Index