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?

Answer 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.

Answer 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.

Answer 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.

Answer 4

According to Wikipedia, the kernel supports file systems of up to 16TB, so that is the largest a partition can be and still be fully used. Not all file systems actually support the full 16TB, of course.