After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 438574 - gparted slowed down when moving partition
gparted slowed down when moving partition
Status: RESOLVED DUPLICATE of bug 546423
Product: gparted
Classification: Other
Component: application
0.3.4
Other All
: Normal enhancement
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2007-05-15 11:37 UTC by Maciej Pilichowski
Modified: 2008-08-07 02:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Maciej Pilichowski 2007-05-15 11:37:29 UTC 
I moved (right to left) &growed ~10GB partition. it took ~10 minutes, I was
delighted.

Then I (in practice: http://bugzilla.gnome.org/show_bug.cgi?id=438514) moved
60GB partition, from right to left. It took ~6 hours maybe. I noticed that
while moving&growing the first, gparted used large chunks, while on the latter
it used (finally) chunks of 128 (bytes?).

Of course it is a dream-wish, but it would be great if gparted could be speeded
up on moving operations (especially from right to left -- no data overlapping
really).
Comment 1 Spike Spiegel 2008-04-24 20:00:21 UTC 
Having the same problem *right now* with the Ubuntu Live CD, perhaps it uses a compatibility filesysten driver. Used blocksize is 64.

Solutions:
1. If estimated time is longer than 1h ask the user:
"Do you really want to start a uncancellable 7h+ operation NOW?"

2. I have 2Gb RAM. Why not read 1Gb sequentially to RAM,
then write to disk? Would only take 100 transactions instead of
3261928 and hard disk arm bearing would say thank you. Hey, even MS-DOS's xcopy did that.
Comment 2 Curtis Gedak 2008-08-07 02:18:55 UTC 
A problem was discovered in the algorithm that attempts to choose an optimum block size for moving or copying partitions.

The new enhanced algorithm will benchmark times with all of the block size possibilities.  Then it will select the block size that took the smallest time to copy.

The previous algorithm would start with a small block size, test the time of a copy, and then try the next larger block size.  As soon as the next larger block size took longer than the previous one, the algorithm would stop and declare the previous block size as the optimal size for the copy operation.  In theory this would appear to be a good algorithm, but due to anomalies in benchmark times the  algorithm would wrongly favour smaller block sizes.

If you believe that the improved algorithm does not shorten the time to move or copy partitions, please feel free to re-open this bug or a new one indicating your new found information.




*** This bug has been marked as a duplicate of 546423 ***