Last Web page update: 4/18/2022, referencing GPT fdisk version 1.0.9
This Web page 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 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 serious a problem 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 using 4096-byte sectors rather than the more common 512-byte sectors to extend the limit to 16 TiB. Unfortunately, as described on this page, neither solution is currently a good one for all cases, although using larger hard disk sectors is an option (and indeed, may be unavoidable) for some disks. (Note that you can use GPT on disks with 4096-byte sectors, so such disks don't require the use of MBR; they just enable it for disks that are between 2 TiB and 16 TiB in size.)
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. (I performed these tests around 2010 and I haven't tested with more recent OSes.)
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. The problem might have been at the driver level, though, in which case you might have better luck on real hardware.
Because Linux, FreeBSD, and Windows 7 and later all have 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 from it in BIOS mode. 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.
Note also that, even if a disk seems to work with a configuration like the one I tested, there's always the risk that a particular program (especially a low-level disk utility, like a filesystem check tool or a program intended to recover deleted files) might misbehave on such a disk. Low-level disk utilities can do a lot of damage when they're buggy, so I strongly recommend against this approach to extending the 2 TiB limit if you can possibly avoid it.
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 have largely shifted from 512-byte to 4096-byte sector sizes, at least on conventional spinning disks. (Western Digital was the first to market, but Seagate and others have followed.) Since partitions are defined in terms of sectors, such a shift can 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, most "bare" drives I am aware of to date (2022) that use 4096-byte sectors include firmware that presents the illusion of 512-byte sectors to the OS. Some disk utilities, including GPT fdisk, report such disks as having different physical and logical sector sizes, the physical sector size being what the disk actually uses and the logical sector size being the size used for partitioning purposes. The use of different physical and logical sector sizes may change in the future, and in fact I know of a few bare drives that uses 4096-byte physical and logical sectors.
A further wrinkle is that some external disks (especially models that connect via a USB cable) do the opposite translation: They combine groups of 512-byte sectors into single 4096-byte sectors. This enables external disks between 2TiB and 16TiB to be partitioned using MBR. Not all external disks make this translation, though. In fact, USB seems to have its own 32-bit limitation, so if you install an over-2TiB disk in an enclosure that does not do this translation, you will probably lose access to most of the disk. The most common symptom is that the disk appears to be the modulo (remainder) of its true size with 2 TiB — for instance, a 3 TiB disk will appear to be 1 TiB in size. When an enclosure does perform this translation, it becomes very difficult to move the disk back and forth between a "translating" enclosure and its direct use in a computer, since the sector size — and therefore partition start and end measurements, in sectors — will change when the disk is moved.
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, in 2010, and again in 2014, I ran benchmarks on Advanced Format drives. 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, disk, and kernel version used for the tests, such operations could take two to twenty-five times as long on misaligned partitions. That's right: up to 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 in most cases, with the exception of some external USB disks. 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.
If you're trying to use an over-2TiB disk with an OS, such as Windows XP, that doesn't support GPT, you may have a problem. Several possible solutions exist that do not involve ugly workarounds, including:
Ultimately, OSes that can't deal with GPT were never really intended to use disks that are large enough to require GPT. Thus, if you find yourself running into this limit, my first reaction is that you should reconsider your OS choice. In 2022, all the major OSes that are under active development support GPT and over-2TiB disks. OSes that lack GPT support have largely been abandoned, and so should be used only with caution, since they're likely to contain security bugs. Still, you may have a reason to want to use a modern disk with an older OS, in which case one of the preceding options may be worth considering.
Go on to "Legacy BIOS Issues with GPT"
Return to "GPT fdisk" main page
copyright © 2009–2022 by Roderick W. Smith
If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main web page.