What is the max partition supported in linux?

Question

May i know the max partition size supported by an Linux system. And how much logical and primary Partition as we can create in an disk installed by linux system?

Solution 1

How Many Partitions

I believe other, faster and better people have already answered this perfectly. :)

There Is Always One More Limit

For the following discussion, always remember that limits are theoretical. Actual limitations are often less than the theoretical limits because either

• other theoretical limits constrain things. (PCs are very, very complex things indeed these days)
• there are always more bugs. (this answer not excluded)

When Limits are Violated

What happens when these limits are violated isn't simple, either. For instance, back in the days of 10GB disks, you could have multi-gigabyte partitions, but some machines couldn't boot code stored after the 1,024th cylinder. This is why so many Linux installers still insist on a separate, small /boot partition in the beginning of the disk. Once you managed to boot, things were just fine.

Size of partitions: MS-DOS Partition Table (MBR)

MS-DOS stores partitions in a (start,size) format, each of which is 32 bits wide. Each number used to encode cylinder-head-sector co-ordinates in the olden days. Now it simply includes an arbitrary sector number (the disk manages the translation from that to medium-specific co-ordinates). The kernel source for the ‘MS-DOS’ partition type suggests partition sizes are 32 bits wide, in sectors. Which gives us 2^32 * 512, or 2^41 bytes, or 2^21 binary Megabytes, or 2,097,152 Megabytes, or 2,048 Gigabytes, or 2 Terabytes (minus one sector).

GUID Partition Table (GPT)

If you're using the GUID Partition Table (GPT) disk label, your partition table is stored as a (start,end) pair. Both are 8 bytes long (64 bits), which allows for quite a lot more than you're likely to ever use: 2^64 512-byte sectors, or 2^73 bytes (8 binary zettabytes), or 2^33 terabytes.

If you're booting off of a UEFI ROM rather than the traditional CP/M-era BIOS, you've already got GPT. If not you can always choose to use GPT as your disklabel. If you have a newish disk, you really should.

Sector Sizes

A sector has been 512 bytes for a long while. This is set to change to 4,096 bytes. Many disks already have this, but emulate 512 byte sectors. When the change comes to the foreground and the allocation unit becomes 4,096 byte sectors, and LBAs address 4,096 byte sectors, all the sizes above will change by 3 binary orders of magnitude: multiply them all by 8 to get the new, scary values.

Logical Volume Manager

If you use LVM, whatever volume you make must also be supported by LVM, since it sits between your partitions and filesystems. According to the LVM2 FAQ, LVM2 supports up to 8EB (exabytes) on Linux 2.6 on 64-bit architectures; 16TB (terabytes) on Linux 2.6 running on 32-bit architectures; and 2TB on Linux 2.4.

Filesystem Limits

Of course, these are the size limits per partition (or LVM volume), which is what you're asking. But the point of having partitions is usually to store filesystems, and filesystems have their own limits. In fact, what types of limits a filesystem has depends on the filesystem itself! The only global limits are the maximum size of the filesystem and the maximum size of each file in it.

EXT4 allows partitions up to 16TB per file and 1EB (exabyte) per volume. However, it uses 32-bit block numbers, so you'd need to increase the default 4,096-byte block size. This may not be possible on your kernel and architecture, so 16TB per volume may be more realistic on a PC.

ZFS allows 16EB files and 16EB volumes, but doubtless it has its own other, unforeseen limits too.

Wikipedia has a very nice table of these limits for most filesystems known to man.

In Practice

If you're using Linux 2.6 or newer on 64-bit machines and GPT partitions, it looks like you should only worry about the choice of filesystem and its limits. Even then, it really shouldn't worry you that much. You probably shouldn't be creating single files of 16TB anyway, and 1 exabyte (1,048,576 TB) will be a surreal limitation for a while. If you're using MBR, and need more than 2 binary terabytes, you should switch to UEFI and GPT because you're operating under a 2TB-per-partition limit (this may be less than trivial on an already deployed computer)

Please note that I'm an old fart, and I use binary units when I'm calculating multiples of powers of two. Disk manufacturers like to cheat (and have convinced us they always did this, even though we know they didn't) by using decimal units. So the largest ‘2TB’ disk is still smaller than 2 binary terabytes, and you won't have trouble.

Unless you use Logical Volume Manager or RAID-0.

Solution 2

There are two limits. On is the support in Linux, the other is the maximum count in the used partition table scheme: It depends if you use the legacy MBR or the newer GPT .

MBR supports four primary partition. One of them could be a extend partition which can contain an arbitrary number of logical partitions limited only by your disk space.

GPT supports up to 128 "primary" partitions.

In the old days, Linux supported only up to 63 partitions on IDE and 15 on SCSI disks because of limited device numbers. Today the kernel can allocate device numbers dynamically (udev is the keyword) so this limits should not be longer valid.

Solution 3

This is not related to the OS itself, but to the partition scheme in use.

The introduction of the gpart man page of FreeBSD has it quite nicely.

Basically you have:

• "MBR" scheme which is the old "DOS" way with, as you said "primary" (up to 4) partitions and logical ones (no real limits - as far as I know).
• "Intel EFI/GPT" scheme, the new way of doing things, with only "primary" partitions and virtually no limits.

So in fact, no real differences with your standard Windows box.

Comments

[Admin]

That depends on partition table type, gpt or mbr, use of LVM or not, then filesystem. You need be more specific about these details in your question for anyone to be able to give you a useful answer.

[Admin]

Note that for eMMC devices, Linux Kernel use MMC_BLOCK_MINORS to limit number of partitions available par device (default value is 8).

[Roger Stewart]

Hum. The 32 bits Linux kernel supports up to 16 TB, but most systems have been 64 bits for years. I routinely build storage servers with 77 TB partitions and even bigger filesystems.

[Simon Gates]

What imposes that one? I know it (or a similar limit) must be there, as I just deployed three servers with UEFI/GPT because they came with 12×2TB disks and Dell assumed we were going to make a single partition out of the lot (!). But I can't for the life of me see where it might be between disk block and kernel. Is it a BIOS boot limitation or something?

[psusi]

Also worth noting is that ext4 currently also uses 32 bit block numbers, giving a max size of 16 TB with the normal 4kb block size. Support for 64 bit block numbers is in the works, but not active yet.

[Simon Gates]

@psusi: Thanks, added. wazoox is referring to MS-DOS labelled devices, and to me that's ambiguous (are we talking whole disks or partitions?)

[psusi]

@wazoox, again, the limit for the MS-DOS label is 2TB, not 16. You can't use more than 2TB of the disk using the MS-DOS label.

[Roger Stewart]

@psusi, yes, that's right. Actually I haven't use MS-DOS label since 2006 or so :) Alexios, Under Linux, you can put an MS-DOS label on a device (disk or RAID array) of any size, but only 2 TB are addressable (anything over 2 TB won't be usable). Nobody should use MS-DOS labels anymore, they're really an outdated relic.

[psusi]

@wazoox, it is required for Windows on non UEFI systems, but then again, Windows is also an outdated relic ;)

[Ezequiel]

2^32 - 1? Why there is minus one