Re: misbehaving partitions

[Andrew Clausen]

Hi Don!

On Thu, Nov 01, 2001 at 11:08:19AM -0600, Don Mulvey wrote:
> Hi Andrew,  I have a couple of scenarios and was wondering what your
> opinion would be regarding them.
> 
> (1) I have seen an occasion where an ebr chain of logical drives has a
> freespace in the middle of it ...

I don't understand what you mean by "freespace".

> and ... an ebr partition table that
> simply chains to the next logical drive, using
> an extended partition record.  This leaves a cylinder of freespace on the
> drive in the middle of the extended partition and seems really strange to
> me because the ebr chain now chains freespace.

Yeah, it is rather strange.

> Sorta like this ... MBR
> ... EBR0 ... FREESPACE ... EBR1  ... DATA_PARTITION.    You see what I
> mean?

Yep.

> EBR0 uses a track of diskspace and the only partition record in its
> table is the extended partition record that chains to EBR1.   I think the
> answer is to throw away EBR0 during discovery (disk probe?) and chain the
> MBR to EBR1.  Otherwise, you create a metadata segment for EBR0 that is 1
> track and a Freespace segment that is 1 track shy from being a full
> cylinder.

Yep.  In libparted I don't store ANYTHING about EBRs.  Parted only
remembers where the primary, logical and extended partitions are.
Everything else is regenerated/recomputed each time.  This hasn't
caused any problems.

I think trying to preserve the old structure will be a nightmare.
What happens if you delete or add new partitions, for example?
(i.e. need to modify the structure in some way)

> (2) If one uses fdisk to create partitions, it will add logical drives to
> the end of the ebr chain and get partitions out of physical order.

Right.  If it didn't do this, then it would "renumber" the other partitions
in Linux.  (Which isn't necessarily a bad thing, but you can see what
the motivation is...)

> Other
> partitioning tools may not like this or have this same behavior.  So, what
> should the correct behavior be?

I'm not aware of any problems of going out-of-order.

Also, I am aware of a problem of changing this policy (to making it
in-order).  Imagine the following setup, from good-old-fdisk:

   Device Boot    Start       End    Blocks   Id  System
   /dev/hdb1            14       127    915705    5  Extended
   /dev/hdb5            39        64    208845   83  Linux

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl    Start     Size ID
 1 00   0   1   13 254  63  126   208845  1831410 05
 5 00   0   1   38 254  63   63   401625   417690 83
  

Notice how partition 5 starts on head 0, not head 1?  It doesn't
have it's own partition table... the only EBR is at the start of the
extended partition itself.  The first logical partition (i.e. the
logical partition in the EBR of the extended partition) never has
it's own partition table, and always starts on head 0 in this way.

If you wanted to "insert" a logical partition before (geographically),
you would normally make this /dev/hdb6, and it would have it's own
EBR.  i.e. the extended EBR would point to an EBR in front of /dev/hdb6,
and that latter EBR would contain the entry for /dev/hdb6.

There is no way of making /dev/hdb5 /dev/hdb6, because this would
require giving /dev/hdb5 it's own partition table, but there is no
room for one.

This is the reason why parted doesn't have a "renumber" command.
(We could allow it in most cases, but I haven't gotten around to it...
it doesn't seem too important anyway ;)

> The evms os2 seg mgr currently mimics
> fdisk but I am about to change it because it doesn't make sense ... it
> really should mimic what os2 does ... and os2 lays them down in physical
> order.   However, the default seg mgr is a different story.   How do you
> think it should behave ... i.e.  should logical partitions be added and
> named in physical order?

I think "no".

BTW: what's the "default" seg mgr?  Does it mean "MS partition tables"?

Andrew