[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: misbehaving partitions
Re: misbehaving partitions
Fri, 2 Nov 2001 20:47:09 +1100
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
> 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
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...)
> 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"?