Limit on # of Partitions - 10.3 & 11.0?

English Install/Boot/Login
#1

I seem to remember (at least in 10.3) that the new drivers (changing from HDA to SDA nomenclature for SATA drives?) imposed a limit of 15 partitions … otherwise old ATA driver module/method had to be selected at installation.

I wish to add another partition to install 11.0 to, for testing. Right now I have:
sda1 is a fat16 boot partition
sda5 is the extended partition container
sda6 to 15 (10 partitions) are various OS’s.

When I use Yast Partitioner in 10.3 it adds the requested new partition right after sda15 in the extended partition, but calls it sda3. My preference is to have it added as sda16 due to the way I have multiboot set up.

So my questions are these:

  • Is this just 10.3’s behaviour because of the “15 partition” limit which, if this is happening, seems to also be a “no more than sda #15” limitation? In other words, there’s two limits: n.g.t sda15, and no more than 15 actual partitions?

  • in my situation, do I have 11 or 12 partitions right now (counting the extended container, which is really a primary partition)? Just to know where I am vis-a-vis any limitations.

  • is this behaviour also in 11.0? My thought here was that if it’s a 10.3 issue, then I’d add the new partition at the time I’m installing 11.0.

  • if the behaviour is also in 11.0, then I guess I have to put up with the “sda3” insertion of the partitioner. Then the question becomes whether there are any functional differences, performance or “gotcha” issues between the hda (limitless, well, 26 in extended) and sda drivers?

TIA.

#2

In suse 10,3 yast>system>partitioner is a explanation how numbering of the partition of a disk goes.
I do not know if that is enough to answer you,re
question

regards
dobby 9

#3

Yes, thanks, I’m aware of that and the basics, but this is a little more involved. Hoping to catch the eye of a Suse expert who can give the answers. Thanks a lot, though.

#4

There are different rules I believe for different types of bios, it’s not a linux limit. For an old fashioned PC type bios it works like this:

The drive has a partition table built into the first sector of the drive (often called the MBR or Master Boot Record). This has space for 4 partitions. Each of these partitons can be either a Primary partition, a definition of space which, when formatted, will be an actual partition, or it can be an Extended partition which is a definition of space which will be allocated later. These partitions are numbered sda1 to sda4.

If you define an Extended partition, what you get in the partition table, is a pointer to another partition table on the drive, this also has space for 4 partitons, but this time you are only allowed to allocate partitions that will be drives, these are numbered sda5-sda8 for the first Extended partition, sda9-sda12 for the second Extended partition etc.

from this you can see that the maximum number of partitons you can define will be 16, define 4 Extended partitons and suballocate each of them 4 times.

As for influencing the actual partition number, I have never found a way to do this, the various partitioning tools seem to insist of working this out for themselves.

#5

Hmmm. Don’t think it works exactly like that. After the post, the conventional BIOS goes to a specified location in the hard drive, the MBR, which contains a little more code plus a four-entry table. These are the primary partitions, one of which may be an extended partition.

If it’s an extended partition, it contains a pointer to the extended partition table which can contain (since it’s not constrained to the tiny 512 byte MBR) a considerable number of entries/partitions. I seem to recall that the max number of partitions on a hard disk, for DOS/Windows for example, is 24 because the floppy allowance is A & B, leaving 4 primary and 20 extended partitions in the C to Z range. My recollection is that there can only be one extended partition per hard disk.

This schema seems to be borne out by my HD example which has one primary partition (a fat16) and one extended partition with 10 partitions (2xfat16’s, 1xW2K-NTFS, 1xWXP-NTFS, a NTFS data drive, a Linux Swap, and five EXT3 partitions to handle data drives and 3 OS’s). I can boot any of the five OS’s, six if you count DOS on Drive C. Only one extended partition, I swear.

However, that’s not the problem I have. From the 10.3 release notes:

“libata uses /dev/sda for the first harddisk instead of /dev/hda. Disks with more than 15 partitions are not handled automatically right now. You can disable libata support by booting with the following kernel parameter:
hwprobe=-modules.pata
Then you see all the partitions > 15 again and can access them for installation.”

Note the “right now” phrase, which begs the question “did it get fixed in 10.3”, and/or "is it also applicable to 11.0:? I’ve read the 11.0 release notes and there’s no mention.

If we look at the partitioning scheme I have, there are 4 primary partition (one DOS, one extended, two unused) defined in the MBR plus 10 in the extended, which gives 14 (at least). So my worry is whether putting another partition or two into the extended area will invoke this libata restriction and make my current Suse 10.2 (2) partitions unbootable/unseeable.

Ditto for 11.0. Thus my original three questions. It’s certainly not something which everyone will hit, but I’d sure like to know the answers.

#6

Beg to differ.

Linux’s SATA support is based on its SCSI
support, which means it inherits the SCSI device numbers. And the SCSI
device numbers were designed for large computers, with lots of
relatively small disks.

As a result, the current device numbering (which goes back to the
beginning of Linux) allows for 128 disks, but only sixteen “minor”
numbers per disk – one for the whole disk, four for the primary
partitions, and eleven (sdx5 to sdx15) for logical partitions.

The 2.6.x kernel in theory would support “larger” device numbers, which
could allow for even more SCSI disks and more partitions per disk – but
that would leave incompatibilities with stuff that expected old-style
device numbers. Last I heard, the kernel team were planning to switch
during the 2.7.x development tree – which shows how long ago that was.
Since the plans for 2.7 were dropped, everything seems to have gone
quiet. The unfinished SCSI job [LWN.net] from 2003 is about the most recent
status update I can find.

15 partition limit on SCSI/SATA drives

I seem to recall that one could try specifying the boot option “all-generic-ide” and maybe can get around the sata limit – although, I’ve never tried it

Good luck:)

#7

Aha, Snakedriver has the answer!

  1. Why it’s 15 partions per disk, using the libata driver (16 minus disk itself)
  2. Any combination of primary/extended partitions can make up the 15 partition limit.
  3. The same restriction exists in 11.0 as in 10.3, using the libata driver.
  4. The only way to get around this restriction (and get back to the conventional 24 partition total limit) is to use/specify the “hwprobe=-modules.pata” parm mentioned in the release notes, or the “all-generic-ide” parm that Snakedriver thinks may do the trick.

The only remaining question I have, then, is whether using the PATA instead of Libata drivers/modules has any ramifications on performance, i.e., will pata be slow as a slug after using libata? Anyone know?

Thanks to Snakedriver et all for the assistance.