You've come to this page because you've asked a question similar to the following:
What's the gen on the 2TiB limit relating to disc drives ?
This is the Frequently Given Answer for such questions.
The 2TiB (2.20TB) limit on disc sizes is a combination of two different limiting factors on the sizes of DASDs in PC/AT compatible machines. The first limiting factor is well known. The second is, unfortunately, far less well known. Both limits must be overcome in order to have and make full use of a disc that is greater than 2TiB in size on a PC/AT compatible machine.
The well-known 2TiB limit is the limit of the MBR-style partition table layout. It stores partition table entries using 32-bit sector addresses and 32-bit sector counts. With the conventional 512 byte sector size, that limits the maximum area that can be spanned by an MBR partition table to 2 terabinarybytes.
The solution for this limit is, of course, to switch to the EFI partition table layout, which still counts and addresses things in terms of single sectors, but that uses 64-bit rather than 32-bit numbers to do so, yielding a far larger 8.0ZiB (9.22ZB) as the maximum size of disc that can be used.
For further discussion of the size limits of the various partition table schemes, see the Frequently Given Answer on disc and volume size limitations.
The far less well known 2TiB limit on PC/AT machines is a limit on the size of a disc volume that uses BIOS parameter blocks and that is bootstrapped using the old style method of loading the volume boot record (VBR) rather than using the new EFI operating system bootstrap mechanism that modern firmwares have now been supporting for some years.
The problem lies in the "hidden sector" field of a version 3.4 BIOS parameter block. Contrary to much modern documentation, whose wishful thinking would have this field no longer used, this field remains very much in use by operating system boot loader programs. It is their only means of determing where the boot volume is on the disc, as the value of the field (in the in-memory copy of the BPB loaded in as part of loading the VBR) records the offset of the boot volume from the start of the disc. (It's the fact that this field needs to be fixed up as the VBR is loaded into memory that stops secondary MBR partitions from being directly bootable without the mediation of a boot manager program.) The boot code in the VBR uses this field to convert volume-relative block numbers into disc-relative block numbers, and without it the VBR wouldn't even be able to properly load the next stages of an operating system's bootstrap loader program.
Unfortunately, this field is again a 32-bit field counting 512 byte sectors. Thus it, too, can only encompass the first 2TiB of the disc. As a consequence, all bootable partitions that use BPBs and VBRs must reside within the first 2TiB of the disc. If they don't, the hidden sectors field will either contain the wrong value entirely, or suffer from 32-bit unsigned integer overflow as parts of the volume are accessed; the boot loader will unknowingly read entirely the wrong parts of the disc for the operating system's bootstrap loader program; and the boot loader will fail in some way.
This limitation applies irrespective of filesystem format and irrespective of whether a disc is partitioned with the EFI partitioning scheme. If someone tells you that the switching to the EFI partitioning scheme, or switching to a filesystem format such as NTFS, ZFS, or suchlike, will wholly solve the 2TiB problem, that person is misleading you by only telling you about half of the job.
The other half of the job is to update to a machine that has EFI firmware and use an EFI boot loader program for one's operating system. With EFI firmwares and operating system boot loaders, disc access to the boot loader program is mediated via the firmware, which understands disc partitions, doesn't need the hidden sectors field in the BPB to tell it where those partitions are, doesn't have this 32-bit limit on sector addresses, and applies the correct offsets for converting from volume-relative block addresses to disc-relative block addresses, without need for the boot loader to do so (or even be aware of the process).