Working Around MBR's Limitations

by Rod Smith,

Last Web page update: 6/26/2011, referencing GPT fdisk version 0.7.2

I'm a technical writer and consultant specializing in Linux technologies. This Web page, and the associated software, is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find GPT fdisk or this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!

Donate $1.00 Donate $2.50 Donate $5.00 Donate $10.00 Donate $20.00 Donate another value
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal

Note: This page is part of the documentation for my GPT fdisk program.

A couple of loopholes exist that may make you think that the 2 TiB limit isn't as imminent a threat as I suggest on my What's a GPT? page. These are the possibility of extending the 2 TiB limit to 4 TiB by literal interpretation of the MBR data structure limits and taking advantage of new developments in disk technology to employ 4096-byte sectors rather than the more common 512-byte sectors. Unfortunately, as described on this page, neither solution is currently a good one, although using larger hard disk sectors may be an option for some people in the near future.

Four for the Price of Two?

MBR records partition locations in terms of the starting sector and the partition's length. Both of these are 32-bit values, so in theory you could use MBR on a 4 TiB disk, so long as all the space after the 2 TiB mark is in a single primary partition, or perhaps in a single extended partition, which could in turn hold many logical partitions. Such a configuration would be somewhat limiting, but it fits within the MBR framework.

To test the practicality of such a configuration, I ran tests using the QEMU machine emulator and its virtual disks, which can appear much larger to a guest OS than to the host OS. I was able to create a 4 TiB virtual disk that was just kilobytes in size on my real disk (although it grew as I manipulated it, of course). I tested with a number of legacy and modern OSes, including Linux, FreeBSD, Windows Me, Windows XP, OS/2, and BeOS. I later ran a followup test with Windows 7 under VirtualBox.

To make a long story short, the only OSes that seemed capable of handling a partition that spanned the 2 TiB mark were Linux, FreeBSD, and Windows 7. Windows Me didn't show a drive icon, and its FDISK reported that it was unable to access the disk. Windows XP saw the disk as being just 8 GiB in size. BeOS reported the disk information correctly in its disk setup tool, but was unable to mount the partition I created in Linux or to create a new filesystem on the partition. OS/2's FDISK reported the already-created partition was smaller than it was; apparently it just ignored everything past the 2 TiB mark. One caveat: It's conceivable that these OSes were interacting with a peculiarity of the QEMU environment to create these problems; however, as Linux and FreeBSD were able to handle the disks, I suspect the real problem was in the OSes themselves.

Because Linux, FreeBSD, and Windows 7 all have relatively mature GPT support, there seems to be limited benefit to carefully crafting a configuration to enable use of MBR on a 2–4 TiB drive—at least, for the OSes I tested. The only case where using MBR on a 2–4 TiB disk would produce a benefit would be if you wanted to boot Windows 7 (or possibly Windows Vista, if it works like Windows 7) from it. Overall, though, I consider 2 TiB to be the practical limit for MBR, since so many OSes can't use MBR's theoretical capacity to manage some configurations of up to twice that size.

Eight for the Price of One?

In December of 2009, Western Digital introduced the first drives using a new technology, known as Advanced Format. In brief, in a bid to overcome various technical limitations unrelated to disk partitioning, drive manufacturers are beginning a shift from 512-byte to 4096-byte sector sizes. (Western Digital was the first to market, but Seagate and others have followed.) Since partitions are defined in terms of sectors, though, such a shift can at least theoretically provide a boon to those attempting to eke a bit more life out of MBR. On a disk with a 4096-byte sector size, the 2 TiB limit of MBR is boosted eight-fold, to 16 TiB. Of course, a shift to 4096-byte sectors will only delay the inevitable doom of MBR, but it could still be useful as a stopgap measure.

Unfortunately, some OSes and utilities include hard-coded assumptions about sector sizes, and will only work properly with hard disks that employ 512-byte sectors. Although I've not tested it for this effect, the claim is that Windows XP can't handle such disks, although Windows Vista and later, as well as Mac OS X and Linux, can. Linux isn't completely immune to this problem, though; although it handles unusual sector sizes well for the most part, the Linux kernel prior to about version 2.6.33 includes a bug that prevents GPT disks from being properly detected on anything but drives with 512-byte sectors. In order to overcome such problems, all drives I am aware of to date (mid-2011) to use 4096-byte sectors include firmware that presents the illusion of 512-byte sectors to the OS. It's conceivable this will change as drives exceed the 2 TiB limit, although the only model I know of with 4096-byte physical sectors of that size is an Advanced Format model that pretends to have 512-byte sectors.

To add further to the confusion, the "faking" of 512-byte sectors by Advanced Format drives creates a need to align partitions to 8-sector (4096-byte) boundaries or risk serious performance problems. This is because many filesystem data structures are aligned to 4096-byte boundaries relative to the partition start, so starting partitions at anything but a 4096-byte boundary results in a need to read or write two physical sectors whenever these disk structures are updated. To test how significant this effect is, I bought a 1 TiB Western Digital WD10EARS drive and ran some benchmarks on it. I found that misaligning the partitions created only minor degradation for read operations and writes of large files, but when writing many small files (as in extracting a Linux kernel tarball), misaligned partitions could degrade performance by huge amounts. Depending on the filesystem, such operations typically took two to twenty-five times as long on misaligned partitions. That's right: twenty-five times as long! (See my IBM developerWorks piece for details.) Of course, if the drive presented itself as a unit with 4096-byte sectors, this problem would vanish—along with compatibility with some OSes and utilities.

The bottom line in terms of extending the life of MBR, though, is that the new 4096-byte sector size isn't yet an improvement. It might help if and when manufacturers expose the true sector size of such disks; however, as in fudging the 2 TiB limit to 4 TiB by starting a partition just before the 2 TiB limit, the OSes that are best prepared for such a change can also handle alternative partitioning systems—most notably GPT.

Go on to "Legacy BIOS Issues with GPT"

Return to "GPT fdisk" main page

If you have problems with or comments about this web page, please e-mail me at Thanks.

Return to my main web page.