NetBSD-Users archive

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

Re: GPT vs BSD-label



On Feb 8,  1:30pm, Swift Griggs wrote:
} 
} Can one use the BSD disklabel to fully replace a GPT or MBR table? I 
} understand why folks want to move from MBR to GPT, but do the same reasons 
} apply to BSD disklabels? In other words, is there any advantage to using 
} GPT over BSD diskabels ?

     Standard BSD disklabels have the same limitation as MBRs as
they use 32-bit numbers for partition start and size.  This means
that they have a 2TB size limit.  In theory, this could be worked
around by using a larger sector size, i.e. using a newer disk that
has a 4KB sector size in native mode.  That would take you to 16TB.
However, given that you can buy 6TB drives off the shelf today,
that's not much better (four drives in a RAID5 array would put you
over that limit).

     I will note that the people over at OpenBSD have done something
to extend disklabel to use 64-bit numbers.  However, as far as I
know, they are the only ones going that route.  Also, their GPT
implementation is a strange hybrid, where they bury an OpenBSD
disklabel and all partitions inside a single GPT partition.  In
other words, they treat GPT the same way that everybody else does
MBR.  As far as I know, they are the only ones that have chosen
that route, which makes their disks incompatible with everything
else.

} The only thing I can think of is that the partitions might be visible to 
} other OS's which aren't savvy about BSD disklabels. In my case, there is 
} no value in that as my disks stay with BSD machines.

     In theory you can put a BSD disklabel at the beginning of a
disk and skip the MBR.  Note that there are some poorly written
BIOSes that will get upset at this.  It is something that I have
done in the past.  However, I find that the hassle of using a
"non-standard" configuration is just not worth it, especially when
you consider that you can't even buy anything smaller then 100GB,
and you'll only save 1MB or less.

     Before, various people jump in, I'll point out that none of
the above applies to people using unusual/obscure/ancient hardware.

}-- End of excerpt from Swift Griggs


Home | Main Index | Thread Index | Old Index