EMBR partition system

[Cixert]

I read in some comments from the forum about an alternative partition system to GPT with the name EMBR that could work with inherited computers and hard disks + 2TB. I am not sure what it is and if there is an operational version. The info in this link says that it is not yet able to write in NTFS and other formats. I don't know if there is another version.

https://www.fysnet.net/embr/index.php

[Tripredacus]

When I was doing the testing work in this thread, it seemed to me the real limitation to how large of disks could be used was determined by where the partition info was being written to the disk. The fact that you could get more than the 2.2 TB in MBR was only possible if you made the second partition before the 2.2 TB boundary. Of course I didn't (and still don't) have a larger disk to test on. So then I thought about why not put all that info someplace else, then I would wonder how much space you could actually use on MBR. This eMBR seems to be using that idea. 

But the issue is still usability. Even with my testings, only Windows 7 could make use of the test disk and XP didn't work. What is still missing in either scenario is getting an actual retail OS to work with disks like these. Even that eMBR site seems to indicate this disk scheme is specifically designed for some specific OS.

[Cixert]

On 1/17/2025 at 4:01 PM, Tripredacus said:

The fact that you could get more than the 2.2 TB in MBR was only possible if you made the second partition before the 2.2 TB boundary. Of course I didn't (and still don't) have a larger disk to test on. So then I thought about why not put all that info someplace else, then I would wonder how much space you could actually use on MBR. This eMBR seems to be using that idea. 

After so many years of trial and error, I am convinced that reading +2TiB MBR is possible because some USB adapters translate the physical sector size from 512 bytes to 4096 bytes. I have not tried formatting partitions with 512 bytes, if we use partitions with a minimum of 4096 bytes it seems to make sense.
In this way the MBR limit is 16 TiB for a single partition.
The problem now is that the new USB adapters I am testing do not have this physical sector translation, so I am looking for an alternative method.
What I do not know is why GPT is able to read +2TiB. In Windows XP with the updated Paragon GPT driver, GPT drives are also limited to 2 TiB, however with the driver old version 8.0.1.0 there is no such limitation.
So it seems that the limitation also affects GPT, although it is bypassed in some way.

[Tripredacus]

The limitation isn't really in the disk type (MBR or GPT) it is in the firmware and the OS. The firmware (BIOS or UEFI) need to know how to address the space, and the OS also needs to know how to do it. It is clear if you go back far enough in time to when boards had disk size limits. I was testing a Pentium II board where the maximum disk size you could use was somewhere under 20 GB. If you put a bigger disk, the BIOS would not recognize the disk and thus not make it available to an operating system. As boards became newer, there was more built-in support. And also we know from the linked thread that the OS is also different, beyond just having drivers. Where the test disk was seen properly in Windows 7 but not XP. 

I think jaclaz has posted before about not particularly liking USB adapters for these kinds of tests because there is no standard and it can be hard for people to get a particular type if it is not mass produced by a big brand. So any testing you can do may not be worthwhile to others if they cannot reproduce or take advantage of it, if the reason why they can't is that they can't find that particular adapter. Of course, it is always worth the effort to tinker with these things regardless of their general availability.

[j7n]

The BIOS limit doesn't come into play except for a boot disk. And you don't need a 2 TB boot disk even for the latest Windows that has expanded to fill its container. Yes on older computers with 8..32 GB limits it did. Under Windows the disk is accessed via a driver and programming the I/O that way. A 4 TB (decimal) disk works fine under Server 2003 x86 and the Intel driver. I think the built in driver might work, but I don't remember as I installed the Intel driver early.

Why the aversion to Server which doens't have all this problems with memory and disk size?

I think if you could coax an MBR disk to work past the 32-bit boundary, there could be data loss in some situations as the numbers wrapped around.

Edited January 22 by j7n

[Cixert]

4 hours ago, j7n said:

I think if you could coax an MBR disk to work past the 32-bit boundary, there could be data loss in some situations as the numbers wrapped around.

I've been using MBR +2TiB for many years and so far I haven't had any problems with data corruption.
The problem I'm encountering is getting new adapters on the market.
I'm trying to switch to GPT but I'm running into a lot of issues on XP, for example the Paragon driver causes corruption if I use PAE to go over 4 GiB RAM on XP.
 

 

On 1/21/2025 at 2:08 AM, Cixert said:

I have not tried formatting partitions with 512 bytes, if we use partitions with a minimum of 4096 bytes it seems to make sense.
In this way the MBR limit is 16 TiB for a single partition.

I finally experimented from Windows Seven x64 with 512 byte cluster size on NTFS. The limit is 1.99 TiB per partition.
NTFS uses 32 bits too.
I think the calculation is 2^32 -1 cluster.
The difference seems to be that GPT calculates physical sectors with 2^64. So partition sizes larger than 2 TiB are allowed if the cluster size is changed to 4kiB.
But then I would not be able to read +2TiB MBR hard drives with 512 byte physical sector with these USB adapters. My new Toshiba 6Tb seems to work fine on XP with MBR. I will do a test to verify that there is no data corruption.

NTFS PARTITION LIMITS
Cluster  0.5 KiB =      1.99 TiB /       2047.99 GiB /        2097151.99 MiB
Cluster     1 KiB =      3.99 TiB /       4095.99 GiB /        4194303.99 MiB
Cluster     2 KiB =      7.99 TiB /       8191.99 GiB /        8388607.99 MiB
Cluster     4 KiB =    15.99 TiB /     16384.99 GiB /      16777215.99 MiB
Cluster     8 KiB =    31.99 TiB /     32767.99 GiB /      33554431.99 MiB
Cluster   16 KiB =    63.99 TiB /     65535.99 GiB /      67108863.98 MiB
Cluster   32 KiB =  127.99 TiB /   131071.99 GiB /    134217727.96 MiB
Cluster   64 KiB =  255.99 TiB /   262143.99 GiB /    268435455.93 MiB
Cluster 128 KiB =   511.99 TiB /   524287.99 GiB /    536870911.87 MiB
Cluster 256 KiB = 1023.99 TiB / 1048575.99 GiB / 1073741823.75 MiB
...and so on to cluster 32768 KiB = 131040.00 TiB

*Values from cluster 2/4/8/16/32/64/128/256 KiB have been calculated by the previous amounts and I have not verified their correct operation.
I think the calculation is 2^32 -1 cluster.

[Tripredacus]

On 1/22/2025 at 1:51 PM, j7n said:

I think if you could coax an MBR disk to work past the 32-bit boundary, there could be data loss in some situations as the numbers wrapped around.

This isn't a given. I do not know if this thought even comes from any actual real world example or if it is just what is thought. In the testing I did, there was no issue with using the entire disk and no data loss. However it may be possible on some implementations that does indeed happen.