bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: control of partition numbers


From: D. Hugh Redelmeier
Subject: Re: control of partition numbers
Date: Tue, 31 Dec 2002 14:45:08 -0500 (EST)

| From: Andrew Clausen <address@hidden>

| > Sometimes I wish to control the partition number of a partition that
| > I've just created or modified.
| 
| It is rather difficult to implement this.

I would expect that exchanging two partition table entries would be
quite easy.

|  There are some combinations
| that are illegal.

Yes: exchanging a logical and primary partition table entry isn't
possible.  For one thing, the space for a primary partition must not
be inside an extended partition but the space for a logical partition
must be inside the extended partition.

|  Also, remember that Parted supports many different
| types of partition tables.

Good point.  Unfortunately, I don't know enough about other types of
partition tables to speak to this.  Perhaps you could describe the
constraints on exchanges for these other types.

|  What you're saying is probably doable,
| but I haven't been able to find a simple clean solution yet.
| 
| BTW, how would users specify the permutation?  Could you give
| some pseudo-screenshots?

Why might one want to control the partition numbers?

- In the Microsoft world, the "device name" or "drive letter" is based
  on the partition number.  You need to control the partition number
  to maintain or adjust the drive letter.

- In the LINUX world, the minor device number (and hence the
  conventional device name) is based on the partition number.
  (I guess that parted's partition number is LINUX's minor device
  number, at least at this time.  Linus sometimes talks of changing
  the minor device number mechanism.)

- LILO and most other boot loaders care about partition numbers.

I've not played with parted on a primary partition (one of the four
possible partitions in the main partition table), only on a logical
partition (one of the many that can be within an extended partition).
Whenever a logical partition is deleted, all later ones get
renumbered.  Whenever a logical partition is added, it becomes last.
So if you delete and recreate a partition, it and all higher-numbered
ones are renumbered -- often inconvenient.


How could parted address these problems?

- Perhaps when the user asks to create a partition, he could specify
  its number.  If the number were in the extended partition, all
  partitions with that number or higher would have their number
  incremented.  If the number were of an existing primary partition,
  parted should refuse.

  This solves the delete/recreate problem, but leaves other imaginable
  ones.  For example, if he created a partition with the wrong number,
  he could not fix up the mistake without deleting a partition and
  recreating it.

- parted could have a command to permute the existing partitions.
  This would neither delete nor create partitions, only move their
  table entries.

  There would need to be restrictions: a primary partition (including
  the whole extended partition) could only be moved to another primary
  partition number; a logical partition could only be moved to another
  logical partition number.

  This is the one that appeals most to me.


How doe you specify a permutation of partitions?

There are many notations used by mathematicians.  For example:

        / 1 2 3 \
        \ 3 1 2 /
(I think parentheses are normally used, but ASCII doesn't have
double-height ones.)  This means that what was 1 becomes 3 and what
was 2 becomes 1 and what was 3 becomes 2.

The tr(1) command suggests a notation for a permutation (but it does
not restrict itself to permutations).  How about a parted command:

        renumber 1 2 3 to 3 1 2

This has more syntax than most parted commands.

It turns out that any permutation can be expressed as a sequence of
exchanges (the exchanges may overlap).  Here is one sequence that has
the same effect as the above:

        exchange 1 3
        exchange 2 3

The good thing is that this has trivial syntax.  The syntax and
semantics are minimal in some sense.

The bad thing is that it may not be easy for a user to think of the
right sequence of exchanges to accomplish what he wants.

A slightly more powerful command would allow a rotation of a number of
partitions:
        rotate-right  1 2 3
        rotate-left   3 2 1

As you can see, rotate-left and rotate-right can accomplish the same
things.  An exchange is the same as a rotation of just two partitions.

A rotate can easily renumber the last (newest) logical partition of into
another slot, moving everything else up:
        rotate-right 5 6 7 8
The latest (8) will become 5, and the former 5, 6, and 7 will each be
bumped up one position.

If I remember correctly, any permutation can be partitioned into a set
of rotates.  I use the word "partitioned" because the rotations are
not overlapping: they can be performed in any order (that is also why
I called them a set, rather than a sequence).  This makes rotation
slightly nicer than exchange.


My recommendation: implement exchange.  It is minimal and yet can
accomplish anything that the others can do.  Although it is slightly
awkward for the user, we don't yet know how often this facility would
be used.


Note that for primary partitions, full power requires that unused
partitions table entries be candidates for exchange.  This reflects
what the underlying partition table allows.  It also enables all
possible control of minor device numbers.  There is no concept of an
unused partition table entry for logical partitions, as far as I
know.


There are some other tasks that can be accomplished simply by changing
partition table entries, but not via permutation.  The constraints on
applicability make them less elegant.

a) move the first logical partition within an extended partition to be
   a primary partition.  This would require changing the extent of the
   extended partition AND moving the partition table entry for the
   logical partition.

b) the reverse of a: move the primary partition just before an extended
   partition into the extended partition, changing the primary
   partition into a logical partition.

c) the same as a, but operating on the last logical partition inside
   an extended partition

d) the same as a, but operating on the first primary partition right
   after the extended partition.

I think that I'd use commands that would accomplish these tasks.  But
not too often.

Hugh Redelmeier
address@hidden  voice: +1 416 482-8253




reply via email to

[Prev in Thread] Current Thread [Next in Thread]