2 TiB limit size in MBR hard drives

[Cixert]

Since a few years ago there is a hoax spread on the Internet saying that the hard disks limits in MBR is 2 TiB. With the excuse that Windows can not address more than 32 bits. The truth is that the limit imposed in 2003 by LBA 48 bits gives the following results, actually 32 bits but according to the cluster size used in formatting, for example:

Cluster 512 (old physical size used on hard drives)
2 ^ 32x512 = 2 TiB limit

Cluster 4096 (current physical size used on hard drives)
2 ^ 32x4096 = 16 TiB limit

Cluster 65536
2 ^ 32x65536 = 256 TiB limit
These references are valid at least for traditional Windows formats, both FAT32 and NTFS.
Also in the format exFAT can be formatted with a size of 131072 bytes

Cluster 131072
2 ^ 32x131072 = 512 TiB limit

However different websites have made a copy and paste an Internet text that says that the limit is in 2 TiB. Western Digital itself has stuck the same text on its website helping to spread the false rumor.

This could have been propitiated because current versions of Windows are intentionally designed to not be able to read MBR disks larger than 2 TiB (checked in Windows 7). Forcing the use of the GPT format in Windows NT 6 (Vista - 7 - 8 - 8.1) (Windows 10 not checked)
When Windows NT 5 (2000 SP2 - XP SP1 -2003) can work perfectly with hard disks larger than 2 TiB in MBR with the specified cluster sizes. Also all current versions of Linux are able to read and work with MBR hard disks larger than 2 TiB (checked since 2008).

Following the line there are external USB hard drive enclosures that are capped to the limit 2 TiB for MBR disks.

Against the physical limits are described above may have MBR hard disks with a single partition of 512 TiB. The catch is that Windows NT 6 is not able to read it by identifying the disk as faulty RAW.

This is an example of a 4 TiB hard drive running perfectly on Windows XP connected to a LogiLink® USB 3.0 to IDE & SATA Adapter with OTB adapter (verified the same result on more than 10 computers running Windows 2000 and 2003).

Windows XP Screenshot:

[ppgrainbow]

Good job getting your 4 TB hard hard drive to work under Windows XP!

Hard drives can be formatted with the exFAT file system of up to 32 MB clusters at 2 ^ 32 sectors for a maximum total of 128 PB (144,115,188,075,855,872 bytes) which is also the maximum for the LBA-48 specification.

Currently, there are no software tools or hard drives to overcome the 128 PB barrier at this time.

Edited February 16, 2017 by ppgrainbow

[jaclaz]

The limit  is not in "cluster" size (that is a characteristic of the filesystem), it is "sector" size (that is a characteristic of the hardware).

Besides that, there are issues in a number of OS in booting from a non 512 bytes sector size hard disk drive (which does not affect obviously "data only" disk drives).

It is not however really a "hoax", the two things belong to different times, the number (of sectors, not clusters) limited by the 32 bit address space in the MBR partition table came out earlier, at a time when disks were still mostly or very largely 512 bytes sectored only and had not actually reached if not maybe in high end disks the 3 terabyte size, and while the disk makers started making the 4k sectored disks (that effectively "move" further the issue to around 16Tb) Microsoft decided to not update existing OS to handle the matter and jumped on the (Intel driven) UEFI/GPT bandwagon  (and to mostly 64 bit).

In other words, until the disks were 512 bytes sectored the limit was there and it was not solvable, and when later it became solvable it was decided by MS to not fully solve it on MBR scheme and adopt GPT (forcibly coupling it with UEFI without any real technical reason) and the disk manufacturers didn't want (or couldn't) provide support for that.

And coupling disks with USB  enclosures may provide "funny results", JFYI:
 

 

jaclaz

 

[dencorso]

See also this other thread:

[Dibya]

You can use gpt in xp by replacing disk.sys from srv2k3 . Need some proper supporting files to ensure stability . I will make it ready soon both for 2k and xp

[Mcinwwl]

8 hours ago, jaclaz said:

It is not however really a "hoax", the two things belong to different times[...]

As far as I understand, he's calling it a hoax because some major companies claim it is impossible, while it's more like 'not supported' and rarely occurring, according to what you have said

[jaclaz]

20 hours ago, Mcinwwl said:

As far as I understand, he's calling it a hoax because some major companies claim it is impossible, while it's more like 'not supported' and rarely occurring, according to what you have said

Yep, but overall it is more than anything else some misinformation and/or outdated info due to the accumulated information on technology that changes (the hard disk hardware) under a "static" piece of software (the Operating System).

At a given date the 2^32-1 sectors limit did imply that the max capacity to be around 2.2 Tb because *all* disks were 512 bytes per sector.

Soon after the hard disk manufacturers found a possible way out by using bigger sector sizes, but in the meantime, due to the "transitioning" via the so-called "AF" drives (that I believe different manufacturers, besides calling them with different names also implemented slightly different) and to the remaining problem (no support for booting from larger than 512 bytes sector disks in most OS's) the piece of info remained valid.

After all, imagine the fuss that would have happened if someone bought a - say - 3 Tb drive only to find out that it was either (512 bytes or AF) not fully accessible or (4Kb) not bootable, I can understand why it was simpler for the manufacturer not to make the distinction, particularly when the good MS guys were trying all they could to ditch MBR in favour of GPT (and BIOS in favour of EFI/UEFI).

The ironic part (as I see it) is that in the meantime SSD's became the *standard* or *almost standard* main boot (internal) devices and they are still - after several years - nowhere nearing the 2.2 Tb size limit, and they are all (or almost all) emulating the 512 bytes sector size anyway.

jaclaz

[NoelC]

On ‎2‎/‎17‎/‎2017 at 6:36 AM, jaclaz said:

The ironic part (as I see it) is that in the meantime SSD's became the *standard* or *almost standard* main boot (internal) devices and they are still - after several years - nowhere nearing the 2.2 Tb size limit, and they are all (or almost all) emulating the 512 bytes sector size anyway.

That limit can easily be an issue, however, with a RAID array of SSDs though.  Given the performance, even considering the cost, I'm always surprised more people aren't building systems based on RAID volumes.

-Noel

Edited February 18, 2017 by NoelC

[jaclaz]

Maybe easily, but not "common", I believe you are the only one I know that uses one of such arrays.

Maybe other people have not the knowledge or cannot afford a similar setup, which even today is not exactly "cheap".

jaclaz
 

[Cixert]

On 16/2/2017 at 9:40 AM, jaclaz said:

It is not however really a "hoax", the two things belong to different times, the number (of sectors, not clusters) limited by the 32 bit address space in the MBR partition table came out earlier, at a time when disks were still mostly or very largely 512 bytes sectored only and had not actually reached if not maybe in high end disks the 3 terabyte size, and while the disk makers started making the 4k sectored disks (that effectively "move" further the issue to around 16Tb) Microsoft decided to not update existing OS to handle the matter and jumped on the (Intel driven) UEFI/GPT bandwagon  (and to mostly 64 bit).

This is interesting. Do you have any links that describe that the MBR limit corresponds to the hard disks physical size sector?
It's to give people who write on Wikipedia that the limit is only 2 TiB.
https://en.wikipedia.org/wiki/Logical_block_addressing

[dencorso]

Quote

<offset> +8 bytes <lenght>4 bytes<description>LBA of first absolute sector in the partition

Hence: 4 bytes = 2^32 values LBA (= linear number) od *sectors*.

https://en.wikipedia.org/wiki/Master_boot_record#PTE

[jaclaz]

You can find *anywhere* a full description of a MBR.

Briefly:

The MBR contains a partition table.

The partition table contains four entries, each 16 bytes.

Each entry describes a partition and contains 4 set of fields (not in this order) check any partition table description:

1) boot/no boot (i.e. hex 80 or hex 0) 1 byte

2) partition ID (1 byte)

3) CHS data, two fields, one describing the start address and one describing the end address, CHS addressing is nowadays obsolete, but it takes anyway 8 bytes.

4) LBA data, two fields, one describing the start address and one describing the number of sectors, each field is 4 byte, and as such it can at the very most represent 2^32-1=0xFFFFFFFF or 4294967295 sectors.

Thus the limit is:
4294967295*512=2,199,023,255,040 bytes

A good question would be what happens if one creates on a (512 bytes/sector) hard disk two partitions, one starting on

 LBA 2048 and extending for (say) 4294967295-2049=4294965246 sectors

and a second one starting on

LBA 4294967294 and extending for 4294967295 sectors?

Would this move (with the limitation of the two partitions) the limit by another 2.2 Tib?

jaclaz

[NoelC]

6 hours ago, jaclaz said:

A good question would be what happens if one creates on a (512 bytes/sector) hard disk two partitions, one starting on

 LBA 2048 and extending for (say) 4294967295-2049=4294965246 sectors

and a second one starting on

LBA 4294967294 and extending for 4294967295 sectors?

Would this move (with the limitation of the two partitions) the limit by another 2.2 Tib?

I almost tried that when you pointed out the possibility some months ago.

I could have created one 8 drive array which would have been a bit under 4 TB total (8 x 480GB), and set up one nearly maxed-out 2 TB C: partition and one V: partition that had all the rest of the space (or just divide it in two).  Once done, I'd have had to restore my System Image backup to the C: volume.  THAT I know how to do.

However I fell short of being confident in what commands in what application I could actually run to create such a "stretched" MBR setup.  It's not something I do every day.  And even trying it would have been destructive, so I just chickened out and created two 4 drive arrays.  The advantage that pushed me over the edge was that the two array approach involved almost no downtime.

An advantage to a single array, partitioned as above, is that any large I/O operation would leverage the performance of all 8 drives, vs. only 4 at a time.  I don't know whether that would practically offset the benefits of being able to do small I/O operations to two different 4 drive arrays simultaneously.  Possibly not - much of what Windows does are relatively small operations, and I have since discovered that both 4 drive arrays can simultaneously do small I/Os at very nearly the same rate of small I/Os with one 4 drive array.  It could actually be that I chose the best performing path for the wrong reasons. 

Still...  One day I may yet test your theory.

-Noel

Edited February 19, 2017 by NoelC

[Dibya]

You can easily patch XP to use RAID5 that will allow using big drives . My 4TB was perfectly usable under xp on my skylake pc but unfortunately system died .

[roytam1]

On Thursday, 16 February, 2017 at 11:15 PM, Dibya said:

You can use gpt in xp by replacing disk.sys from srv2k3 . Need some proper supporting files to ensure stability . I will make it ready soon both for 2k and xp

IMHO it's worth mentioning that XP with srv2k3's disk.sys doesn't make your XP accessing >2.2TB disk in full capability.

and storport support is missing in XP so no workaround for accessing >2.2TB disk besides Paragon GPT loader w/ (S)ATA controller working in IDE mode.