Disc and volume size limits

You've come to this page because you've asked questions similar to the following:

What's the gen on the 1024 cylinder limit relating to disc drives ? What other size limitations apply ?

This is the Frequently Given Answer for those questions.

Introduction

One of the most confusing topics for people to get their minds behind are the disc and volume size restrictions that their hardwares, firmwares, and softwares impose upon them. This is a complex area, and often the blame is apportioned wrongly.

Volume sizes are constrained by five things: The APIs and the capabilities of the the firmware, the APIs and the capabilities of the driver and operating system softwares, the disc I/O command hardware interface, the partitioning scheme being employed, and the actual on-disc filesystem format.

The origin of the 1024 cylinder limitation

The 1024 cylinder limitation is a limitation in the system firmware.

On IBM PCs and compatibles, the system firmware (the BIOS ROM), provides routines for real-mode code to access DASDs (direct access storage devices - i.e. discs, mainly). These routines operate in terms of cylinders, heads, and sectors, and the maximum cylinder number that can be used is 1023.

Real-mode code calls the BIOS by placing parameters in CPU registers and issuing one of several INT instructions. For DASD access, the instruction is INT 13h. The cylinder, head, and sector numbers are packed (in a rather bizarre fashion) into various CPU registers. The sector number occupies 6 bits, the head number occupies 8 bits, and the cylinder number occupies 10 bits. With 10 bits, one can represent only the numbers from 0 to 1023.

These INT 13h functions have existed since the original IBM PC.

Softwares that are affected by the 1024 cylinder limitation

Any software that uses the system firmware routines to access DASDs will be affected by the 1024 cylinder limitation. Essentially, the software will only be able to "see" the first 1024 cylinders of the disc. We'll come back to the exact ramifications of this later on.

MS-DOS, PC-DOS, DR-DOS/OpenDOS, and FreeDOS all rely directly on the BIOS routines for access to DASDs, so their limitations will affect these operating systems both during boot and whilst running.

Other operating systems rely on the BIOS routines to solve a "chicken and egg" problem; namely that they cannot access discs using their own disc device drivers until those device drivers have been loaded, and they cannot load those device drivers without accessing the disc. So at boot time they use the system firmware routines. Particularly, their boot sectors use the system firmware routines.

The exact extent of the use of the system firmware for disc access, beyond the boot sectors, varies from operating system to operating system.

• Windows NT uses the firmware to load NTLDR, NTDETECT.COM, NTOSKRNL.EXE, HAL.DLL, various system files including one of the registry hives, and all of the device drivers that are in the "boot" class.

• Linux uses the firmware to load the kernel (and ramdisc) image.

• OS/2 Warp uses the firmware to load OS2LDR, OS2KRNL, installable filesystem (IFS) drivers, and base device (ADD) drivers.

• Multi-boot utilities such as IBM's Boot Manager and LILO use the firmware to read the partition table, and to read the boot sector of the selected operating system into memory.

All of these things thus have to reside in the BIOS-addressible portion of the boot disc. Because many of them are ordinary disc files, which can live anywhere in their containing volume, this in turn means that the volumes containing the files must be wholly within the BIOS-addressible portion of the boot disc.

The correct way to fix the 1024 cylinder limitation

The correct way to fix the 1024 cylinder limitation is to provide a new set of DASD access routines in the system firmware that don't limit the cylinder number to 10 bits. And indeed this has long since been done. The routines in question are known as the Phoenix/IBM/Microsoft INT 13h extensions (or sometimes as "EDD"), and have been supplied as standard in most manufacturer's BIOS ROMs since around 1997. The INT 13h extensions operate in terms of a 64-bit linear block number, rather than addressing devices using cylinders, heads, and sectors, meaning that the limit on the BIOS-addressible area of the disc is a lot higher.

But simply providing the routines is only half of the solution. All of the softwares that uses the BIOS for DASD access need to be updated to use the new extensions throughout. The degree to which this has happened varies from software to software:

• DOS-Windows: DOS-Windows 95 OEM Service Release 2 was the first operating system to use the INT 13h extensions in all parts of its boot process.

• IBM OS/2 and IBM Boot Manager: IBM OS/2 Warp Server for E-business was the first release of IBM OS/2 to use the INT 13h extensions throughout its boot process. IBM OS/2 WSfE also comes bundled with a revised IBM Boot Manager that also uses the INT 13h extensions. This latter has since been incorporated into IBM OS/2 Warp Client, beginning with version 4.0.14.

• Windows NT: Windows NT 2000 was the first release of Windows NT to use the INT 13h extensions throughout its boot process.

• Non-Microsoft DOS: No known release of PC-DOS, DR-DOS/OpenDOS, or FreeDOS uses the INT 13h extensions.

• LILO:From version 21.4 onwards, LILO can be configured (with the lba32 option) to use the INT 13h extensions.

Once all of an operating system's boot code has been modified to use the INT 13h extensions instead of the original BIOS routines, the 1024 cylinder limitation is completely lifted. There is no reason that any boot file need reside within the first 1024 cylinders of the disc, and boot volumes may cross, or even reside wholly above, the 1024 cylinder line.

How the industry prevaricated by applying bodges for a whole decade

The industry first hit the 1024 cylinder limitation when hard disc sizes started to exceed half a GiB. You may have heard of a "504MiB limitation" or perhaps a "528MB limitation". These are just the BIOS 1024 cylinder limitation in disguise. They only apply to ATA DASDs.

The reason that 1024 cylinders equated to 504MiB(528MB) is that the number of bits for the cylinder, head, and sector numbers provided by the disc controller chips on ATA discs is not the same as the number of bits used when calling INT 13h. (INT 13h has 10 bits for the cylinder, 8 bits for the head, and 6 bits for the sector, yielding a maximum possible addressible disc area of 7.87GiB/8.45GB. The disc controller chips had 16 bits for the cylinder, 8 bits for the sector, but only 4 bits for the head, yielding a maximum possible addressible disc area of 127.5GiB/136.9GB.) However, the ATA BIOS hard disc routines simply passed the cylinder, head, and sector numbers supplied in the INT 13h call straight through to the device controller chip registers. (In most modern ATA BIOSes one can select this behaviour by configuring a disc as "NORMAL".) The maximum for each number was thus the minimum of the two maxima imposed by the INT 13h interface and the disc controller chip register interface. This meant that the maximum possible addressible disc area was actually 504MiB/528.4MB (1024 cylinders multiplied by 63 sectors per track multiplied by 16 heads).

Rather than solve the issue there and then, the industry postponed the problem for several years by stealing an idea from SCSI and modifying it slightly, to produce the concept of "Translation".

The main BIOS in a PC is only capable of controlling ATA devices. Access to SCSI discs is provided by a BIOS extension, either on the SCSI Host Adapter card or (on some motherboards with built-in SCSI) contained in the same ROM as the ATA BIOS. The SCSI BIOS hooks into the INT 13h service vector, inserting its own service routine ahead of the service routine of the ATA BIOS. Code that uses INT 13h services can then access SCSI DASDs in the same way as ATA DASDs. (This is why SCSI Host Adapter cards without BIOS extension ROMs are often referred to by the misnomer "non-bootable". It's a misnomer because it's not the card that is booted. It is the disc. It's simply that the BIOS code that reads the boot sector into memory uses the same INT 13h routines to access DASDs as does everything else. Without the INT 13h hook, it is impossible to access a SCSI DASD at boot time.)

The idea of translation originated in the SCSI world because SCSI DASDs are not actually addressed in terms of cylinders, heads, and sectors at the hardware level. SCSI has always addressed discs as a linear sequence of blocks, numbered from zero upwards. But the INT 13h interface operates in terms of cylinders, heads, and sectors. Therefore, the INT 13h routines in the SCSI BIOS had to invent a completely fictitious device geometry, that bore no relation to the actual SCSI device whatsoever, purely for the sake of the PC system firmware. It would then use that geometry to translate from the cylinder, head, and sector numbers used by callers of INT 13h services into SCSI block numbers used by SCSI proper.

The exact scheme for inventing the geometry varies from one SCSI BIOS manufacturer to another, but in general it involves picking a fixed number of "heads" and "sectors per track", yielding a fixed "cylinder" size. The total size of the SCSI DASD in blocks is then divided by this cylinder size to yield the number of "cylinders" on the disc. The most common choices are 64 heads and 32 sectors per track, yielding a handy cylinder size of exactly 1MiB; and 256 heads and 63 sectors per track, yielding a cylinder size of 7.87MiB. Some SCSI BIOSes even allow one to choose from one of several schemes, via an option in the SCSI BIOS' SETUP utility. Adaptec SCSI BIOSes call this option "Extended BIOS translation for drives > 1Gbyte", for example, which switches between 64 heads/32 sectors and 256 heads/63 sectors. Most SCSI BIOSes provide at least these two choices.

ATA BIOSes stole the idea of fictitious geometries from SCSI, and divorced the disc geometry as seen at the INT 13h interface from the disc geometry as used when talking to the ATA disc controller chip itself. The geometry used to talk to the disc controller chip became the "logical geometry", and the geometry used by callers of the INT 13h routines became the "translated geometry". (The term "physical geometry" meant the geometry used in the disc unit itself. Ironically, the geometry used to talk to the disc controller chip was already divorced from the actual physical geometry of ATA DASDs.)

There are two major schemes used for creating the translated geometry from the logical geometry. Both allow the full 8 bits of the head number, as supplied at the INT 13h interface, to be used, instead of only 4 bits. This meant that the maximum BIOS-addressable portion of the disc rose from 504MiB/528MB to 7.87GiB/8.45GB, allowing the industry to postpone the onset of the 1024 cylinder problem.

• The first scheme simply doubles the number of heads and halves the number of cylinders until the number of cylinders is less than 1024 (or the number of heads is greater than 127). In most modern ATA BIOSes this is known as "LARGE".

• The second scheme operates more like the fictional geometry creation of SCSI BIOSes in that it fixes the number of heads at 256 and the number of sectors per track at 63, and divides the total number of blocks on the disc by 16128 to obtain the number of cylinders. In most modern ATA BIOSes this is known as "LBA". Since it relies on logical block addressing commands that ATA disc controller chips are not required to provide, it is not usable with all ATA DASDs.

Translation was only ever a bodge, however, that didn't fix the actual problem. All that it gave users were problems with moving discs between machines whose ATA BIOS manufacturers had decided to use different translation schemes. The industry simply hit the 1024 cylinder problem all over again, some years later, when disc sizes started to exceed 7.87GiB.

Software limitations in protected mode operating systems

Once booting is complete, a protected mode operating system relies solely on its own protected mode device drivers for hard disc access. So any limitations are imposed by software and are unrelated to the BIOS. Fortunately, no protected mode operating system imposes the same daft 10 bit limitations as the BIOS INT 13h interface does. Indeed, some of the limitations are exceedingly generous.

OS/2 device drivers

OS/2 Warp may have a 16-bit device driver model invented in 1987, but that driver model uses a full 16 bits for cylinder, head, and sector numbers in I/O request packets. OS/2 base device drivers can thus address discs of up to 128PiB/144.1PB . (You may not have seen those abbreviations used before in discussions of disc sizes. They stand for "petabinary-", denoting 2 to the power 50, and "peta-", denoting 10 to the power 15.)

This is well into the realms of silly numbers here, as no disc hardware supports discs that large. It is presented simply in order to point out that the base device drivers under OS/2 impose no practical limitations on disc sizes.

OS/2 applications

There is no 1024 cylinder limitation for native OS/2 softwares.

Direct access to physical discs from application mode code is via the IOCTL_PHYSICALDISK category of I/O Control functions. These use a TRACKLAYOUT data structure. Once again, this is a 16-bit data structure invented in 1987. But once again, this uses the full 16 bits for cylinder, head, and sector numbers. Applications can thus also address, in direct I/O operations, discs of up to 128PiB/144.1PB .

OS/2's fdisk

Ironically, OS/2's fdisk tries to be a good neighbour, and refuses to create FAT partitions that cross or lie wholly beyond the 1024 cylinder line. It does this on the grounds that whereas HPFS partitions are not visible to DOS, FAT partitions are, and because — as mentioned above — no flavour of DOS uses the INT 13h extensions, all FAT partitions must be within the first 1024 cylinders for DOS not to become confused when trying to access their contents. In my opinion, this restriction should be eliminated. OS/2 has no problem with FAT partitions wherever on the disc they may be, and this is, after all, OS/2's fdisk. It should be able to create any partition that OS/2 itself would be happy with. Being a good neighbour to DOS is all very well, but not at the expense of disallowing things that OS/2 itself is perfectly happy with.

Microsoft's scandisk

Microsoft's scandisk (which is only capable of deal with volumes formatted as FAT) allocates a block of virtual memory and reads the entire FAT into it. This limits the overall size of a FAT to 16MiB. What this implies depends from the FAT width.

For FAT32, this limits the overall number of clusters in the volume to 4,177,920, which in turn limits the volume size. For a 32KiB cluster size, this limits the volume to 127.53 GiB.

See Microsoft's Knowledgebase article #184006.

Filesystem-specific limitations

Filesystem layouts impose some limitations of their own on the size of volumes.

FAT

All FAT filesystem types use 8 bits to store the number of sectors per cluster, meaning that clusters can be up to 128KiB in size. (This is ridiculously large, of course. The disc cache would be reading and writing 256 sectors at a time, even for 1 byte files. Performance would go through the floor.) In practice, however, operating systems try to be compatible with MS-DOS, which is unable to deal with cluster sizes greater than 32KiB because of internal 16-bit limitations. The optimum cluster size for use with Windows NT, because of the way that its cache manager works, is 4KiB.

FAT12 uses 12 bits to store cluster numbers, FAT16 uses 16 bits, and FAT32 uses 24 bits. Each is thus limited as to the number of clusters in a volume. Because several cluster number values are reserved as special marker values, the maximum number of clusters is slightly less than the maxima that the bit widths alone imply. The volume size limits are thus constrained by a combination of the bit widths and the number of sectors in a cluster.

HPFS

The HPFS filesystem has no notion of clusters. HPFS works solely in terms of disc sectors, and uses 32-bit numbers to store sector addresses in all of its structures, just like the MBR partition table scheme and the SCSI command set. With the usual 512 byte sectors, this makes the maximum size of an HPFS volume 2TiB/2.20TB.

Even such a large volume will only use 1KiB (2 sectors) to store a 1 byte file: one sector for the data and one sector for the file's f-node. Contrast this with a 2TiB FAT32 volume where a 1 byte file requires 128KiB of disc space.

The HPFS filesystem driver in OS/2 Warp masks off the top 5 bits of a sector address, which reduces the maximum volume size to a "mere" 64GiB. This is, however, a coding flaw in one particular HPFS driver, which can (and in my opinion should) be fixed. The actual filesystem structure on disc doesn't share this limitation.

HPFS2

Like HPFS, the HPFS2 filesystem has no notion of clusters. HPFS2 works solely in terms of disc sectors. Unlike HPFS, HPFS2 uses 64-bit numbers to store sector addresses in all of its structures, just like the partition table and the SCSI command set. With the usual 512 byte sectors, this makes the maximum size of an HPFS2 volume 8.0ZiB/9.22ZB.

As with HPFS, even such a large volume will only use 1KiB (2 sectors) to store a 1 byte file with HPFS2: one sector for the file sector data themselves and one sector for the file's FileNode.

NTFS

NTFS allocates space in terms of clusters, which in theory may range from 0.5KiB to 128KiB in size, just as for FAT. NTFS uses 64-bit fields to store cluster numbers. So the theoretical maximum size of an NTFS volume, with the largest possible cluster size (which is, as for FAT, ridiculously large and inefficient), is 2YiB.

In practice, the maximum size of an NTFS volume is much lower, because Microsoft's NTFS drivers in Windows NT use 32-bit numbers for cluster numbers, not 64-bit numbers, and only support cluster sizes up to 64KiB. This reduces the practical maximum size of an NTFS volume to 256TiB/281.5TB. As with HPFS, this is a coding flaw in one particular NTFS driver, not a limitation of the filesystem structure on disc.

From Windows NT version 3.51 onwards, the maximum cluster size (when new volumes are high level formatted) is further reduced to 4KiB, both because this is an efficient size for paging and because the NTFS file compression mechanism places this limit on cluster sizes, reducing the practical maximum size of an NTFS volume yet further to 16TiB/17.6TB.

Partition table-specific limitations

Partition table schemes impose their own limits on the sizes of both DASDs and volumes. The MBR, BSD disklabel, and EFI partition table schemes store partition locations as <start,length> tuples. The bit widths of the length fields constrain the sizes of individual partitions; and the bit widths of the start fields constrain the sizes of the areas of the disc that the partition table scheme can cover.

Most partition table schemes use the same bit widths for both the start and the length fields of a tuple, and thus the maximum partition size and the maximum partitionable area of the disc are the same. The MBR partition table scheme uses 32-bit words for both fields, as does the original version of the BSD disklabel partitioning scheme. The revised version of the BSD disklabel partitioning scheme uses 48-bit words. The EFI partition table scheme uses 64-bit words.