From: "R. G. Newbury" <newbury@xxxxxxxxxxxx>
Message: 10 Date: Mon, 2 Oct 2006 15:32:14 -0700 From: "jdow"
>In an abstract sense I'd love to know what limits a disk to only one
>extended partition other than legacy and sloppy code. I've had two
>extended partitions on other systems before. I think I did that with
>the 2.0.x kernel tree at one time, too. All that's needed is simply
>traversing the partition tables sensibly.
Having had to rebuild partition tables a few times from some
over-enthusiastic misuse of Partition Magic, the answer is that:
a) partition table space is limited to four primary partition entries
(this is 'legacy specification');
b) any of those entries can be a primary partition of an extended
partition type, but you cannot have any primary partitions after that entry;
c) a logical partition entry in an extended partition has a pointer to
the start of next logical partition: the system follows the chain to
find subsequent partitions;
d) normally, the partition chain is linearly increasing, but you can
have entries which jump 'back'. This completely defeats some operating
systems, especially OS/2 (IIRC Windows does not mind this: I don't know
about Linux and I have NO desire to find out the hard way!); and
e) you may have had 2 extended partitions by creating an extended
partition INSIDE the first extended partition. If you use a program
which lets you change the table entries directly (partedit), this would
be easy to do, since you are only changing a type byte, but I wouldn't
do that unless I was testing to see if the OS could handle it, meaning,
the drive had no important information on it, which naturally, was never
the case, when I had to figure out what had gone wrong with my drives!
Partition Magic creates partitions in monotonic order notwithstanding
that you may be jumping 'back' to fill a gap. It does NOT go back and
change the pointers to push the new partition into the chain. If you are
careful to move and expand partitions starting from the bottom and only
create partitions in free space at the end, you can avoid this
problem...maybe!
I have no idea if the linux-based equivalent tools work the same way,
but I strongly suspect they do due to the very nature of the beast.
Backup the table first and backup your data.
I've violated every one of those bullets quite successfully with
various versions of Linux and Windows over the years with the singular
and obvious exception of item A.
When you look at the data layout of the whole affair you could have
four extended partitions and a properly designed piece of software
could trace out to find each one of the partitions. It just needs to
know to look at ALL four of the basic partitions and parse each one
for either a primary partition description or an extended partition
description. If a given basic partition description is extended then
the extended partition table for that extended partition needs to be
traced out. Skipping around should not matter either. All that matters
is that data partitions in no way overlap each other's boundaries. Nor
can extended or primary partitions overlap any primary partitions.
So in practice IMAO it is sloppy coding that prohibits multiple
extended partitions not any basic design requirement inherent in the
various partition description tables.
(As a side note the partition tables the Amiga had actually could
support descriptions for nested data partitions quite safely. There
were "reserved" blocks at the head of a partition and similar reserved
blocks at the end of a partition space. I explored these possibilities
as I wrote the partitioning software supplied by a major Amiga hard
disk controller manufacturer. I have dug deeply into the partition
tables for DOS/IX/Windows, not necessarily out of any great desire
to do so. And as noted above there is no GOOD reason that the various
limitations in the latest fdisk software exists other than the limited
minds of the current developers. They have the arrogance to presume
nobody needs to go outside their little mental box. Sometimes people
do have to go outside the tight little mental boxes of people like
the fdisk developers. They SHOULD have a switch that says, "I know
damn well what I am doing and take responsibility for any data carnage
that I produce with my silliness or oddball needs." Then it should
allow anything the descriptors can describe unambiguously as long as
no lethal overlaps exist.)
{^_^} Joanne, who has wanted a piece of the fdisk developer's hides
for several years now. I fondly remember the 5.0 fdisk that
was sane.
