On 2011-02-08 05:06, consused wrote:
> robin_listas;2287567 Wrote:
>> The previous limit was because the number had to be a byte.
>> Did you understand anything?
> Not really, since a byte (hex FF) provides for 256 different values
> (0-255), but I’m probably missing something.
> Assuming the new limits are
> now implemented and not still an “idea” :), these were the old limits I
> referred to:
>> Linux has a 15 partitions limit on a sata drive, but I’m not sure if
>> that includes the 3 primary partitions or its just for logical
>> partitions. I think the limit is 60 logical partitions on an IDE
>> connected drive.
> Sata and pata (IDE) had different limits, I guess due to different
> geometry, but the same byte limitation?
No, due to linux driver specifications.
The document is “/usr/src/linux/Documentation/devices.txt”. The device
nodes in "/dev/ have each a “major” number and a “minor” number - and both
are (were!) one byte in size:
cer@Telcontar:~> l /dev/sda*
brw-rw---- 1 root disk 8, 0 2011-01-29 22:15 /dev/sda
brw-rw---- 1 root disk 8, 1 2011-01-29 22:15 /dev/sda1
brw-rw---- 1 root disk 8, 10 2011-01-29 22:15 /dev/sda10
brw-rw---- 1 root disk 8, 11 2011-01-29 22:15 /dev/sda11
brw-rw---- 1 root disk 8, 12 2011-01-29 22:15 /dev/sda12
brw-rw---- 1 root disk 8, 2 2011-01-29 22:15 /dev/sda2
brw-rw---- 1 root disk 8, 3 2011-01-29 22:15 /dev/sda3
brw-rw---- 1 root disk 8, 4 2011-01-29 22:15 /dev/sda4
brw-rw---- 1 root disk 8, 5 2011-01-29 22:15 /dev/sda5
brw-rw---- 1 root disk 8, 6 2011-01-29 22:15 /dev/sda6
brw-rw---- 1 root disk 8, 7 2011-01-29 22:15 /dev/sda7
brw-rw---- 1 root disk 8, 8 2011-01-29 22:15 /dev/sda8
brw-rw---- 1 root disk 8, 9 2011-01-29 22:15 /dev/sda9
(In this computer I don’t have more than 15 partitions, so I can’t show
And the definition is this:
8 block SCSI disk devices (0-15)
0 = /dev/sda First SCSI disk whole disk
16 = /dev/sdb Second SCSI disk whole disk
32 = /dev/sdc Third SCSI disk whole disk
240 = /dev/sdp Sixteenth SCSI disk whole disk
Partitions are handled in the same way as for IDE
disks (see major number 3) except that the limit on
partitions is 15.
Se that the minor byte is used both to number disks and their partitions.
Only 4 bits are allocated for the partition, so we have 16 disks and
sixteen partitions for the major of “8”.
It is not a limitation of the driver, but a limitation of how the
major,minor numbers were originally defined many years ago. And the
definition was limited to use two bytes, because that was the kernel
definition. It was discussed to change to “word” instead, but it was not
accepted. In fact, from the posts i mention below, the change to “word” was
made, but not used (not used to have more device nodes, I mean).
> Anyway it’s good the old limits are no longer. Do you know roughly when
> the change took place?
On openSUSE 11.2. I’m unsure about 11.1, though.
Date: Aug 2007
To: OS-en <firstname.lastname@example.org>
Subject: Re: [opensuse] opensuse-10,3beta2 on on64bit: IDE disk gets
recognised as /dev/sda
In this mail a workaround was mentioned to allow for more than 16 partitions.
This other email explains the situation at that moment - I’ll copypaste:
Date: Sat, 25 Aug 2007 23:48:21 -0400
From: Greg Freemyer <>
To: OS-en <email@example.com>
Libata being a part of scsi is considered a major shortcoming. The
plan according to the lkml-ide list is to eventually seperate it out
into its own infrastructure. Maybe use a /dev/diskX type of naming
If that is done they should be able to support more partitions again.
FYI: The core libata devels that I see on lkml-ide are:
Jeff Garzik - libata architect - Redhat employee
Tejun Heo - libata coder and extender - Novell employee
Alan Cox - libata/pata implementer - Redhat employee
In particular without Tejun Heo of Novell, the kernels sata support
would not have advanced much in the last couple years. Jeff just
doesn’t seem to have time to do much more than review the massive
amount of new code that Tejun produces. As an example 80% of Tejun’s
PMP code has still not been reviewed by Jeff and that was submitted a
couple months ago.
So if Novell is going to make a kernel push to support 16+ partitions
with libata it will likely be via getting Tejun to do the hard work of
turning libata into a full fledged subsystem under the overall
direction of Jeff Garzik.
Date: Tue, 12 Jan 2010 06:22:43 -0500
From: Felix Miata <>
Subject: Re: [opensuse] Maximum number of partitons
> What is the case with pre 10.3 systems? They use the old driver and see >
all IDE partitions, but how they handle SATA disks?
Until the 2.6.28 kernel, which means release of 11.2 with its 2.6.31,
SATA/SCSI/Firewire users were limited to 14 partitions with filesystems per HD.
>> However, in 11.2 you have again unlimited (AFAIK, really unlimited)
>> of partitions with scsi names, ie, the new library. This is new, and I
>> understand, pushed by suse/novell on the kernel
Some other distros wanted upgraders to be forced to move to LVM if they
wanted more than 14 partitions/HD. Novell was in fact a proponent of a less
intrusive upgrade path, and instrumental in its implementation in libata.
Date: Tue, 12 Jan 2010 14:09:35 +0100 (CET)
From: Steffen Winterfeldt <@suse.de>
Subject: Re: [opensuse] Maximum number of partitions
On Tue, 12 Jan 2010, Felix Miata wrote:
> On 2010/01/12 11:19 (GMT+0100) Istvan Gabor composed:
>> 11.2 Reference guide says (Chapter 2.1.1): “The maximumnumber of logical
>> partitions is 15 on SCSI, SATA, and Firewire disks and 63 on (E)IDE
> This part of the doc didn’t get the update it needed. 11.2 has a 2.6.31
> kernel. The post 11.1/2.6.27 kernels lifted the libata (necessary for SCSI,
> SATA, Firewire) restriction from 15 to (AFAIK) 63.
There is no longer a partition limit. It’s really unlimited (for most
practical purposes) now. E.g. on my test disk I have:
brw-rw---- 1 root disk 259, 301 Jan 12 14:50 /dev/sda204
Partitions just get free minor numbers assigned dynamically.
Related bugzillas: 309070, 305095, 218122, maybe more.
But I did not locate where the work of Tejun Heo was explained. As you see,
it is pretty recent.
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)