Working Around MBR's Limitations

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

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.