OSDev.org

Traditional partition tables will run out of steam once hard disk sizes reach 2Tb, and since they are already reached the 250Gb region it seems to me that the writing is on the wall. Should we all be thinking in terms of GPT partition tables?

Like it or not, we are probably going to be stuck with whatever Microsoft, Intel et al see fit to foist upon us.

EFI seems to be the "new" standard that is going to replace the traditional MBR/Partition table. Unfortunatley, since it is fugly.

mathematician wrote:(...) and since they are already reached the 250Gb region (...)

Pardon me, they're selling 1TB disks already, I even bought a 500G last week (it had the lowest €/GB ratio)

I already have a Terabyte Drive, and 2 Terabyte one's have existed for some time from all the major hard drive manufacturers.

@bewing:EFI != GPT. Just because GPT was specified as part of the EFI standard, there is no reason a BIOS cannot support GPT, or that EFI Firmware cannot support MBR Partitioning. Infact it is possible you could produce MBR boot code that supports GPT in order to bridge the gap.

Not quite what I meant.
But in any case, if we are going to resist the downward slide into complete UEFI compliance, then all we have to do is adopt a slight modification of the current MBR/Partition table. There are at least 3 unused bytes (maybe even 6, depending on how you count) in each 16 byte entry in that table for all current drives -- ie. for any drive bigger than 8GB. All we have to do is use them to extend the LBAstart and Sectorcount entries to 44 bits. Then the problem goes away.

Hi,

bewing wrote:But in any case, if we are going to resist the downward slide into complete UEFI compliance, then all we have to do is adopt a slight modification of the current MBR/Partition table. There are at least 3 unused bytes (maybe even 6, depending on how you count) in each 16 byte entry in that table for all current drives -- ie. for any drive bigger than 8GB. All we have to do is use them to extend the LBAstart and Sectorcount entries to 44 bits. Then the problem goes away.

I see things from a different perspective - this would just make things worse: a general purpose OS would need to support MBR and GPT and your modification, rather than just MBR and GPT. It's 50% more hassle...

If you want to improve the partition table, you'd probably want something smarter - something that has more fault tolerance (e.g. 2 partition tables in case one is damaged), something that isn't limited to 4 primary partitions, something that identifies partitions properly, etc.

@mathematician: The absolute disk size limit for MBR is 3.999999999068677426 GiB, with one "almost 2 TiB" partition starting at LBA address 0xFFFFFFFF (and one or more other partitions below that). Also, most hard drive manufacturers would call this a 4.39804651008 TB disk drive (almost "4.4 * 10^9" rather than almost "4 * 2^40").

Of course the size of a single hard drive isn't the worst limiting factor - worst case is hardware RAID controllers, where several physical disks are combined into a single logical disk.


Cheers,

Brendan

I ran into the real problem on windows 2003 r2 64bit server...

I have a h/w raid controller mated to 4 750gb disks in Raid 5...

That something like 2.25 Redundant TBs...

When I first booted windows... it was like "hey, nice 1.99 tb disk".... and I was all like "no wai"...

After clicking around for a bit, I saw that the disk manager had an option to upgrade to a GPT disk.

I did that and got all my space.

-Rich

P.S. 100th post...

@mathematician: The absolute disk size limit for MBR is 3.999999999068677426 GiB, with one "almost 2 TiB" partition starting at LBA address 0xFFFFFFFF (and one or more other partitions below that). Also, most hard drive manufacturers would call this a 4.39804651008 TB disk drive (almost "4.4 * 10^9" rather than almost "4 * 2^40").

The way I do my arithmetic, the greatest number of sectors addressable with 32 bits is 2^32, which with 512 byte sectors gives 2^41 bytes. A kilobyte is 2^10 bytes, which makes a terabyte 2^40 bytes. Dividing the one by the other, 2^41 / 2^40 = 2Tb.

Brendan wrote: It's 50% more hassle...

Well, not if I'd be implementing a modified MBR instead of implementing GPT at all.

Brendan wrote: If you want to improve the partition table, you'd probably want something smarter...

The one thing that I'd really want, that you didn't list, is the inclusion of a single universally-accepted Unified Boot Loader that truly does everything. Another thing I'd insist on, is that a decent partition table scheme wouldn't waste more than a handful of sectors off my disk, if all I wanted was to have just one partition with just one OS on my disk. Since EFI/GPT fail both these tests, I think they are fugly standards. Or, at least they were developed too early, before the boot loader exists and/or has become accepted.

mathematician wrote: the greatest number of sectors addressable with 32 bits is 2^32

The available read modes are 28bit addressing and 48bit addressing. There is no 32bit addressing mode, so "addressable" is not the issue. Brendan's math is right for total disk availability using a standard 32bit partition table, and 48bit addressing. Partition#1: LBAstart=1, Sectorcount= 4G-2. Partition #2: LBAstart=4G-1, and Sectorcount=4G-1. Total disk usage: 8G-2 sectors. (Where G=2^30, of course.)