GNOME Bugzilla – Bug 566381
uses wrong blocksize for moving partition
Last modified: 2009-01-12 19:51:03 UTC
Please describe the problem: resized and moved partition for the "perform readonly test" it makes a "finding optimal blocksize" which is my case 16384 sextors (i wonder if it shouldn't be higher cause of 32Mb cache) but when he actually starts to move the partition it only uses a blocksize of 64 the line reads "copy 829209764 sectors using a blocksize of 64 sectors" that takes about 17 hours ... way too long cause in 16 hours i'm joining a lanparty Steps to reproduce: 1. say resize and move 2. make partition smaller and move it to the end so you have free preceding space 3. watch and get old Actual results: it takes to long Expected results: that it would use the blocksize it determined to be optimal ( one of the lines says "optimal blocksize is 16384 sectors") Does this happen every time? don't know yet, still needs 17 hours to finsih Other information: easiest way to solve? just copy&paste the code for "finding optimal blocksize" to be executed before the move command?
Thanks for reporting this bug. I thought it was fixed with bug #546423 but it appears that you have discovered a situation in which it does not select an optimal size. My suspicion is that the larger cache sizes on modern disk drives foil the algorithm which tries to determine the optimum block size. You can view the algorithm by searching for "finding optimal blocksize" in the following GParted_Core.cc file: http://svn.gnome.org/viewvc/gparted/trunk/src/GParted_Core.cc?revision=1005&view=markup Do you have any suggestions on how to improve the algorithm?
you were right, it happened that i saved log, the point is, that the 64 sector move is faster then the 128 sectors so the algorithm stops on line 1837 the while loop starts which determines the best speed, i don't really get how the code is working, but if the loop would no matter what test all sector sizes it would solve the problem here the interesting log part move filesystem to the right ( EXECUTING ) perform readonly test 01:26:26 ( SUCCESS ) using internal algorithm read 829275300 sectors finding optimal blocksize read 32768 sectors using a blocksize of 128 sectors 00:00:01 ( SUCCESS ) 32768 of 32768 read 0.548744 seconds read 32768 sectors using a blocksize of 256 sectors 00:00:00 ( SUCCESS ) 32768 of 32768 read 0.454571 seconds read 32768 sectors using a blocksize of 512 sectors 00:00:01 ( SUCCESS ) 32768 of 32768 read 0.395759 seconds read 32768 sectors using a blocksize of 1024 sectors 00:00:00 ( SUCCESS ) 32768 of 32768 read 0.318539 seconds read 32768 sectors using a blocksize of 2048 sectors 00:00:00 ( SUCCESS ) 32768 of 32768 read 0.312597 seconds read 32768 sectors using a blocksize of 4096 sectors 00:00:01 ( SUCCESS ) 32768 of 32768 read 0.269535 seconds read 32768 sectors using a blocksize of 8192 sectors 00:00:00 ( SUCCESS ) 32768 of 32768 read 0.264228 seconds read 32768 sectors using a blocksize of 16384 sectors 00:00:00 ( SUCCESS ) 32768 of 32768 read 0.251454 seconds optimal blocksize is 16384 sectors (8.00 MiB) read 829013156 sectors using a blocksize of 16384 sectors 01:26:23 ( SUCCESS ) 829013156 of 829013156 read 829275300 sectors read perform real move ( EXECUTING ) using internal algorithm copy 829275300 sectors finding optimal blocksize copy 32768 sectors using a blocksize of 64 sectors 00:00:03 ( SUCCESS ) 32768 of 32768 copied 2.36359 seconds copy 32768 sectors using a blocksize of 128 sectors 00:00:02 ( SUCCESS ) 32768 of 32768 copied 2.51185 seconds optimal blocksize is 64 sectors (32.00 KiB) copy 829209764 sectors using a blocksize of 64 sectors ( EXECUTING )
Would you please check the version of GParted and post it back here? You can find the GParted version by using the menu Help -> About.
GParted 0.3.8 I use ubuntu 8.10
Thank you for the response. I was mislead by the version number that this bug was opened under (0.4.1). Please, in future, report the proper version number when you open the bug report. This bug was already fixed in version 0.3.9. Changing bug Version from 0.4.1 to 0.3.8 *** This bug has been marked as a duplicate of 546423 ***