Editing partitions is slow

Bug #89357 reported by Trouilliez vincent on 2007-03-03
84
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: ubiquity

I am testing Herd5, though the issue is not new...

Probably because I have 9 partitions to look after, and probably because I use Ubiquity a lot ;-) to test the advanced partitioner mostly, I get more and more annoyed at the slowness of the partitioner. That is, for each and every partition, no matter what I do on it (disable it, or select a mount point, or format it), it takes a little while to complete the operation, and also pops up a "Scanning disks" progress bar".
I can understand that it needs to scan the hard drives when launching the partitioner, obviously, but why does it need to scan them 20 times ? If I select a mount point or tick the "format" check box, why does it need to scan the disks all the time ?
It's particularly annoying, considering that the text installer, which I thought now was the new base of the graphical installer, IS NOT slow, nor does it pop up any progress bat or anything.

Here is hoping you can do some magic in time for the final release ! ;o)

Colin Watson (cjwatson) wrote :

Yeah, it's due to the way we drive the underlying partitioning code, which I haven't yet optimised. I hope to get some time to do this before Feisty releases. Basically, it's slow because in order to figure out what to display on the partition list screen we need to navigate through many different screens of the underlying text installer.

Changed in ubiquity:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Mikel Ward (mikelward) wrote :

I assume this is the one I just saw when trying to install Intrepid RC.

It was painfully slow.

Each time I deleted a partition or added a partition, I had to wait about 30 seconds while it re-scanned the partitions.

I have two SATA drives with simple layouts (sda = SCSI 1: sda1 = 80 GB ntfs, sda2 = 78 GB ext3, sda3 = 2 GB swap; sdb = SCSI 3: sdb1 = 500 GB+ ntfs).

Why on earth does it take this long?

LimCore (limcore) wrote :

Still true for 9.04.

Evan (ev) wrote :

Bug 394575 is related.

Francisco T. (leviatan1) wrote :

Before it was slow, but in karmic was very very slow.
15 minutes to setup 5 partitions!!

I installed kubuntu, with the new intaller, Could this be the problem?

Jarl (jarl-dk) wrote :

These bugs are potential duplicates: bug 89357, bug 164030, bug 282193, bug 341095, bug 288450, bug 480957

LimCore (limcore) wrote :

This retarded installer is annoying milions of users world wide ;) Please fix this seriously.. Still true for 9.10

Hein van Rensburg (hvralpha) wrote :

And now for Lucid 10.4 RC. The installer only detects one of my 4 processors on my fast intel system and took ages to install.
This must be something to do with which kernel it loads using a single processor version.

Evan (ev) wrote :

LimCore,

Please refer to the code of conduct (http://www.ubuntu.com/community/conduct) before making any further comments.

Evan (ev) wrote :

Hein,

All of our kernels support SMP. If you think the kernel is not using all of your processors, please run `ubuntu-bug linux`.

Please do not post new bugs as comments in existing bugs.

Jarl (jarl-dk) wrote :

This has improved a lot in Lucid.

Still I find it a bit slow. But not much slower than the rest of the installer-wizard. Which in general I find a bit slow. So to me I think this bug (regarding editing partitions only) is solved.

What do the rest of you think?

I think editing partitions is an intrinsically slow process, but Ubiquity's partition manager is about as fast as GParted or faster, so I think this bug is solved. I'm using Natty.

Changed in ubiquity (Ubuntu):
status: Confirmed → Fix Released

It still refreshes the partition table after every change, which seems unnecessary. In GParted I can setup 15 partitions one after another without delay, the click apply and let it do it's thing. In Ubiquity I make 1 partition, wait, make another partition, wait, and still nothing is actually written to the disk until I click next, when I have to wait yet again.

In the past, partitioning with Ubiquity was absolutely painful. Now it doesn't seem painful, but I do still have to wait needlessly between steps; my hardware is just 3+ years newer.

What's been fixed exactly? That I have a Core2 Quad instead of an Athlon XP? That sounds like a workaround.

There is obviously a problem since, if you read my original report and the first comment on it:

A) The TEXT/alternative installer has NO sluggishness whatsoever.

B) Colin Watson himself, who wrote the ubiquity partitioner, acknowledged that it was slow and explained why.

So please don't pretend that it's "fixed".. nothing is fixed, despite the numerous years that have elapsed. It would more honest to just say "we can't be bothered to make it just work like it should, let's close this bug report". At least I would understand that...

Changed in ubiquity (Ubuntu):
status: Fix Released → Confirmed

I experience similar behaviour during installation of Ubuntu 13.10 (and previously I experienced it during installation of Ubuntu 11.10).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers