Hi,

I've currently got the following partition table on my disk:

Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        2933    23559291    c  W95 FAT32 (LBA)
/dev/hda4            2934       14593    93658950    f  W95 Ext'd (LBA)
/dev/hda5            2934        6376    27655866    c  W95 FAT32 (LBA)
/dev/hda6            6377       10201    30724281    c  W95 FAT32 (LBA)
/dev/hda7           10202       13134    23559291   83  Linux
/dev/hda8           13135       14409    10241406   83  Linux
/dev/hda9           14410       14473      514048+  82  Linux swap
/dev/hda10          14474       14593      963868+   6  FAT16

I don't like that FAT16 partition at the end, so I thought I'd add it to
hda6, because hda6 is empty at the moment, so I don't have to backup data.
So, what I do is, delete 6 and 10 and add a new partition. That results in:

Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        2933    23559291    c  W95 FAT32 (LBA)
/dev/hda4            2934       14593    93658950    f  W95 Ext'd (LBA)
/dev/hda5            2934        6376    27655866    c  W95 FAT32 (LBA)
/dev/hda6           10202       13134    23559291   83  Linux
/dev/hda7           13135       14409    10241406   83  Linux
/dev/hda8           14410       14473      514048+  82  Linux swap
/dev/hda9            6377       10201    30724281   83  Linux

Partition table entries are not in disk order

The new partition, hda9, is now fragmented over the drive. The first bit is
before hda6, the last bit after hda8. Can this cause problems, anywhere?

TIA
--
To send me, Halfgaar, email, remove remove from my email address.

[ Post a follow-up to this message ]

Halfgaar wrote:

>  ___Device_Boot______Start_________End___
___Blocks___Id__System
> /dev/ hda1___*___________1________2933____2355
9291____c__W95_FAT32_(LBA)
> /dev/ hda1___*___________1________2933____2355
9291____c__W95_FAT32_(LBA)


> /dev/ hda4____________2934_______14593____9365
8950____f__W95_Ext'd_(LBA)
> /dev/ hda4____________2934_______14593____9365
8950____f__W95_Ext'd_(LBA)


> /dev/ hda5____________2934________6376____2765
5866____c__W95_FAT32_(LBA)
> /dev/ hda5____________2934________6376____2765
5866____c__W95_FAT32_(LBA)

> /dev/ hda6____________6377_______10201____3072
4281____c__W95_FAT32_(LBA)
> /dev/ hda9____________6377_______10201____3072
4281___83__Linux

> /dev/ hda7___________10202_______13134____2355
9291___83__Linux
> /dev/ hda6___________10202_______13134____2355
9291___83__Linux

> /dev/ hda8___________13135_______14409____1024
1406___83__Linux
> /dev/ hda7___________13135_______14409____1024
1406___83__Linux

> /dev/ hda9___________14410_______14473______51
4048+__82__Linux_swap
> /dev/ hda8___________14410_______14473______51
4048+__82__Linux_swap


> /dev/ hda10__________14474_______14593______96
3868+___6__FAT16

... take a look at it as it's grouped by the start/end blocks.
something doesnt read correctly here. the second entry (line)
in each group is the "after" new partition
.
--
<<   http://michaeljtobler.homelinux.com/   >>
<klieber> or replace them with transparent gifs?
<klieber> (which is pronounced with a hard 'g', btw)
<rac> i got your jeef right here, buddy

[ Post a follow-up to this message ]

mjt wrote:

> ... take a look at it as it's grouped by the start/end blocks.
> something doesnt read correctly here. the second entry (line)
> in each group is the "after" new partition
> .

Oh, fragmented partitions arent even't possible obviously. I didn't pay
enough attention. The new partition would be the same size as the old
hda6, as you showed. There was appearently still space left to make
another parition. That partition would be exactly as big as the old
FAT16 one. So, all I would do this way is change parition numbers.

Is the only way of merging hda10 with another partition a tool like
Partition Magic? Are there any good Linux partitioning tools BTW that
can accomplish the same?

--
To send me, Halfgaar, email, remove remove from my email address.

[ Post a follow-up to this message ]

Halfgaar wrote:
 
[vbcol=seagreen]
> Oh, fragmented partitions arent even't possible obviously.

... let's equate this to the physical world. have you
ever seen those filing cabinets that have those metal,
adjustable dividers in them? you can move the the
dividers front to back, up to the point where you "bump"
into another divider, or the front or the back of the
drawer.

let's say you have a drawer with three dividers in it,
providing equal size to each "partition". and let's
further say that the back-most partition is filled and
you want to make room so that that last partition can
hold more file folders.

so what is the procedure?

you have to move (slide) the last divider towards the
second one, so that the second partition is now
smaller, thereby make the third partition larger.

this is how a hard disk is partitioned: physically.
you *CAN* create logical partitions, but you havet to
use a LVM tool for this to be accomplished. you would
specify one or more partitions to be logically grouped
and represented as a single partition.

with physical partitioning (fdisk), you'll be defining
partitions using a range of blocks. period, the end 

you asked about tools to "resiz" partitions and then
move stuff around. personally, i dont recommend PM
because it can trash a partition table.

if you REALLY want to do this correctly, you should
back up all the partitions that will be affected and
then wipe away the partitions and re-create the scheme
you require, then copy back the data
.
--
<<   http://michaeljtobler.homelinux.com/   >>
Preudhomme's Law of Window Cleaning:
It's on the other side.

[ Post a follow-up to this message ]

In message <cc4shv$tr4$1@news2.tilbu1.nb.home.nl>, Halfgaar
<voor_achter@yahoo.remove.com> writes
>Hi,
>
>I've currently got the following partition table on my disk:
>
>   Device Boot      Start         End      Blocks   Id  System
>/dev/hda1   *           1        2933    23559291    c  W95 FAT32 (LBA)
>/dev/hda4            2934       14593    93658950    f  W95 Ext'd (LBA)
>/dev/hda5            2934        6376    27655866    c  W95 FAT32 (LBA)
>/dev/hda6            6377       10201    30724281    c  W95 FAT32 (LBA)
>/dev/hda7           10202       13134    23559291   83  Linux
>/dev/hda8           13135       14409    10241406   83  Linux
>/dev/hda9           14410       14473      514048+  82  Linux swap
>/dev/hda10          14474       14593      963868+   6  FAT16
>
>I don't like that FAT16 partition at the end, so I thought I'd add it to
>hda6, because hda6 is empty at the moment, so I don't have to backup data.
>So, what I do is, delete 6 and 10 and add a new partition. That results in:
>
>   Device Boot      Start         End      Blocks   Id  System
>/dev/hda1   *           1        2933    23559291    c  W95 FAT32 (LBA)
>/dev/hda4            2934       14593    93658950    f  W95 Ext'd (LBA)
>/dev/hda5            2934        6376    27655866    c  W95 FAT32 (LBA)
>/dev/hda6           10202       13134    23559291   83  Linux
>/dev/hda7           13135       14409    10241406   83  Linux
>/dev/hda8           14410       14473      514048+  82  Linux swap
>/dev/hda9            6377       10201    30724281   83  Linux
>
>Partition table entries are not in disk order
>
>The new partition, hda9, is now fragmented over the drive. The first bit is
>before hda6, the last bit after hda8. Can this cause problems, anywhere?
>
It's not fragmented, the new partition is the old hda6. What you do have
is, as fdisk says, partition tables not in disk order. This may upset
some software, but at least one of my two main PCs is normally in this
state. I tend to move partitions around. Some partitioning programs will
freak out at this, but I've seen no problems with real software.

There isn't much you can do to actually merge the old hda6 and hda10
easily. Partitions do have to be contiguous areas on the physical drive.
If you want to live dangerously, you can use fdisk and dd to move the
old hda7-9 down the drive and create a new partition in the free space,
but do back it all up first. Given the old partition sizes, it should be
possible without hooking in a temporary second drive. It's a bit risky,
and I'd use a second drive to make it safer.

If you do this from a separate Linux (tomsrtbt, knoppix or similar) then
you should be able to shift the existing Linux partitions transparently,
but this is an area where black magic rules, and it may not work for
obscure reasons.

You don't say what you have mounted on the existing Linux partitions,
nor what your directory usage is. If you're intending to use the new
larger partition for Linux, you may be better off dividing your existing
directories between the old partitions, maybe even splitting the old
partitions. /usr and some directories under it are usually quite large
in my systems. /home is large in some systems. Linux doesn't have to be
one big partition.

If the new partition is to be FAT, then you don't have much choice. Back
up the old hda10 (you don't say what happened to the data on it),
downshift hda7-9, create the new partition and restore hda10 to it. Best
of luck.
--
Joe

[ Post a follow-up to this message ]

>>Partition table entries are not in disk order 
> It's not fragmented, the new partition is the old hda6. What you do have
> is, as fdisk says, partition tables not in disk order. This may upset
> some software, but at least one of my two main PCs is normally in this
> state. I tend to move partitions around. Some partitioning programs will
> freak out at this, but I've seen no problems with real software.
>
> There isn't much you can do to actually merge the old hda6 and hda10
> easily. Partitions do have to be contiguous areas on the physical drive.
> If you want to live dangerously, you can use fdisk and dd to move the
> old hda7-9 down the drive and create a new partition in the free space,
> but do back it all up first. Given the old partition sizes, it should be
> possible without hooking in a temporary second drive. It's a bit risky,
> and I'd use a second drive to make it safer.

Do not use dd for this, use parted, or buy Partition Magic.
A lot safer, (although you still should back-up the data)

The reordering itself is relatively easy done with sfdisk.
There may be some inpact on booting though if you specified
any /dev/hda??'s anywhere, eg in your fstab or lilo.conf.

sfdisk does not move the partitions, just renames them so
they are in disk order again.

Use 'sfdisk -d /dev/hda > table.hda' to dump the table,
reorder the entries and feed the new table into sfdisk
with `sfdisk /dev/hda < table.hda`

Eric

[ Post a follow-up to this message ]

mjt wrote:

> Eric Moors wrote:
> 
>
> ... i prefer to steer clear of PM - it's trashed
> the tables on more than one occassion
> .

All partitioning tools I know can on some occassions
behave badly. As long as you do not mix them though, you
should be ok. PM is very strict (but indeed not that fault tolerant).
If you have it though, use it. If you never use fdisk or any other
partitioning tool to touch the ptbl just PM, it will most likely
not fail.
All other tools are less intuitive, or flexible.
Parted, with or without the QT frontend is coming close.

The fdisk/dd path is a no-go area unless you know what you are doing.

Eric

[ Post a follow-up to this message ]