GNOME Bugzilla – Bug 546423
Algorithm to determine Optimal Block Size (for copy) appears wrong
Last modified: 2009-01-12 19:51:03 UTC
Please describe the problem: Hi. Don't know if this is a bug at all, but I thought I'd submit it anyways. I recently repartitioned a Western Digital 160GB SATA drive (8MB cache) to accommodate Ubuntu 8.04. Roughly speaking, the actions required were as follows: 1. Delete some partitions 2. Move a 30GB partition to the end of the drive and grow it to 90GB 3. Move a 13GB partition and grow it to 30GB 4. Create a new ext3 partition The move of the 30GB partition took over 3 hours and was performed using a block size of 64 sectors. The move of the 13GB partition took only a couple of minutes and was performed using a block size of 16 384 sectors. Naturally this surprised me, so I checked out the log (which I've attached below). It appears the program (libparted?) uses an odd algorithm to determine the optimal block size for the copy operations. It copies a fixed amount of data using each of 64, 128, 256, ... 16384 sectors (for my drive), calculates the time and scales it, and then picks the block size corresponding to the lowest time. This all sounds fine. However the algorithm also appears to assume that COPY TIME IS A MONOTONE DECREASING FUNCTION BLOCK SIZE. This seems to have happened when computing the optimal block size for the 30GB partition - here is the log output: perform real move 03:26:45 ( SUCCES ) using internal algorithm copy 61432497 sectors finding optimal blocksize copy 32768 sectors using a blocksize of 64 sectors 00:06 ( SUCCES ) 32768 of 32768 copied 6.24682 seconds copy 32768 sectors using a blocksize of 128 sectors 00:06 ( SUCCES ) 32768 of 32768 copied 6.25982 seconds optimal blocksize is 64 sectors (32.00 KiB) Having seen that 128 sectors was slower than 64 sectors, the algorithm terminated and chose 64 sectors as the optimal block size. I don't know whether this assumption is valid or not, but mathematically it is unsound. I think it's quite possible that drives could exhibit "humped" behaviour as a function of block size. Programmatically it is also strange. Presumably it was coded as some kind of optimisation, to find the optimal block size faster. But computing the time at each one of these 9 block sizes is so fast (compared to the overall operation) that it's unecessary. Especially if there is a chance it gets it wrong and you end up performing the entire move operation 64 sectors at a time. If my understanding is correct, I would say the optimal algorithm OVERALL is to compute the copy time at each block size (in my case 9 points, but this no doubt depends on the drive's cache size) without making ANY assumptions on how the drive's performance behaves as a function of block size. Then choose the best block size and perform the copy operation. Since the copy operation itself will take faar more time than computing the optimal block sizes (50-60GB partitions are common), it is more important that THIS operation be done optimally (at the optimal block size). One should *not* be optimising the algorithm to pick the best block size. Steps to reproduce: This is hardware/setup dependent - don't think it can be reproduced. Actual results: Expected results: Does this happen every time? Only tried it once, but if my understanding is correct this will happen quite often. Other information: GParted 0.3.5 Libparted 1.7.1 Delete Logical Partition (ntfs, 59.50 GiB) from /dev/sda 00:01 ( SUCCES ) calibrate /dev/sda9 00:00 ( SUCCES ) path: /dev/sda9 start: 187799913 end: 312576704 size: 124776792 (59.50 GiB) delete partition 00:01 ( SUCCES ) ======================================== Delete Logical Partition (ntfs, 9.97 GiB) from /dev/sda 00:00 ( SUCCES ) calibrate /dev/sda8 00:00 ( SUCCES ) path: /dev/sda8 start: 166899348 end: 187799849 size: 20900502 (9.97 GiB) delete partition 00:00 ( SUCCES ) ======================================== Delete Logical Partition (ntfs, 19.63 GiB) from /dev/sda 00:00 ( SUCCES ) calibrate /dev/sda6 00:00 ( SUCCES ) path: /dev/sda6 start: 64308258 end: 105466724 size: 41158467 (19.63 GiB) delete partition 00:00 ( SUCCES ) ======================================== Move /dev/sda6 to the right and grow it from 29.29 GiB to 92.77 GiB 03:48:50 ( SUCCES ) calibrate /dev/sda6 00:01 ( SUCCES ) path: /dev/sda6 start: 105466788 end: 166899284 size: 61432497 (29.29 GiB) calculate new size and position of /dev/sda6 00:00 ( SUCCES ) requested start: 118013490 requested end: 312576704 requested size: 194563215 (92.77 GiB) new start: 118013553 new end: 312576704 new size: 194563152 (92.77 GiB) check filesystem on /dev/sda6 for errors and (if possible) fix them 00:00 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda6 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 31453438464 bytes (31454 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 26366 MB (83.8%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 3225 MB 0 $MFTMirr : 10537 MB 1 Ordinary : 31454 MB 32 You might resize at 26365145088 bytes or 26366 MB (freeing 5088 MB). Please make a test run using both the -n and -s options before real resizing! move filesystem to the right 03:48:38 ( SUCCES ) perform readonly test 21:53 ( SUCCES ) using internal algorithm read 61432497 sectors finding optimal blocksize read 32768 sectors using a blocksize of 128 sectors 00:02 ( SUCCES ) 32768 of 32768 read 1.76463 seconds read 32768 sectors using a blocksize of 256 sectors 00:01 ( SUCCES ) 32768 of 32768 read 1.16765 seconds read 32768 sectors using a blocksize of 512 sectors 00:01 ( SUCCES ) 32768 of 32768 read 0.698581 seconds read 32768 sectors using a blocksize of 1024 sectors 00:01 ( SUCCES ) 32768 of 32768 read 1.15839 seconds optimal blocksize is 512 sectors (256.00 KiB) read 61301425 sectors using a blocksize of 512 sectors 21:48 ( SUCCES ) 61301425 of 61301425 read 61432497 sectors read perform real move 03:26:45 ( SUCCES ) using internal algorithm copy 61432497 sectors finding optimal blocksize copy 32768 sectors using a blocksize of 64 sectors 00:06 ( SUCCES ) 32768 of 32768 copied 6.24682 seconds copy 32768 sectors using a blocksize of 128 sectors 00:06 ( SUCCES ) 32768 of 32768 copied 6.25982 seconds optimal blocksize is 64 sectors (32.00 KiB) copy 61366961 sectors using a blocksize of 64 sectors 03:26:33 ( SUCCES ) 61366961 of 61366961 copied 61432497 sectors copied move partition to the right 00:00 ( SUCCES ) old start: 105466788 old end: 166899284 old size: 61432497 (29.29 GiB) new start: 118013553 new end: 179446049 new size: 61432497 (29.29 GiB) updating bootsector of ntfs filesystem on /dev/sda6 00:02 ( SUCCES ) echo 71be0807 | /usr/bin/xxd -r -p | /bin/dd conv=notrunc of=/dev/sda6 bs=1 seek=28 4+0 records in 4+0 records out 4 bytes (4 B) copied, 0.00697776 s, 0.6 kB/s check filesystem on /dev/sda6 for errors and (if possible) fix them 00:00 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda6 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 31453438464 bytes (31454 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 26366 MB (83.8%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 3225 MB 0 $MFTMirr : 10537 MB 1 Ordinary : 31454 MB 32 You might resize at 26365145088 bytes or 26366 MB (freeing 5088 MB). Please make a test run using both the -n and -s options before real resizing! grow filesystem to fill the partition 00:01 ( SUCCES ) run simulation 00:00 ( SUCCES ) ntfsresize -P --force --force /dev/sda6 --no-action ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 31453438464 bytes (31454 MB) New volume size : 31453434368 bytes (31454 MB) Nothing to do: NTFS volume size is already OK. real resize 00:01 ( SUCCES ) ntfsresize -P --force --force /dev/sda6 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 31453438464 bytes (31454 MB) New volume size : 31453434368 bytes (31454 MB) Nothing to do: NTFS volume size is already OK. calculate new size and position of /dev/sda6 00:00 ( SUCCES ) requested start: 118013553 requested end: 312576704 requested size: 194563152 (92.77 GiB) new start: 118013553 new end: 312576704 new size: 194563152 (92.77 GiB) check filesystem on /dev/sda6 for errors and (if possible) fix them 00:00 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda6 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 31453438464 bytes (31454 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 26366 MB (83.8%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 3225 MB 0 $MFTMirr : 10537 MB 1 Ordinary : 31454 MB 32 You might resize at 26365145088 bytes or 26366 MB (freeing 5088 MB). Please make a test run using both the -n and -s options before real resizing! grow partition from 29.29 GiB to 92.77 GiB 00:00 ( SUCCES ) old start: 118013553 old end: 179446049 old size: 61432497 (29.29 GiB) new start: 118013553 new end: 312576704 new size: 194563152 (92.77 GiB) check filesystem on /dev/sda6 for errors and (if possible) fix them 00:01 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda6 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 99616333824 bytes (99617 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 26366 MB (83.8%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 3225 MB 0 $MFTMirr : 10537 MB 1 Ordinary : 31454 MB 32 You might resize at 26365145088 bytes or 26366 MB (freeing 5088 MB). Please make a test run using both the -n and -s options before real resizing! grow filesystem to fill the partition 00:07 ( SUCCES ) run simulation 00:03 ( SUCCES ) ntfsresize -P --force --force /dev/sda6 --no-action ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 99616333824 bytes (99617 MB) New volume size : 99616330240 bytes (99617 MB) Checking filesystem consistency ... Accounting clusters ... Space in use : 26366 MB (83.8%) Collecting resizing constraints ... Schedule chkdsk for NTFS consistency check at Windows boot time ... Resetting $LogFile ... (this might take a while) Updating $BadClust file ... Updating $Bitmap file ... Updating Boot record ... The read-only test run ended successfully. real resize 00:04 ( SUCCES ) ntfsresize -P --force --force /dev/sda6 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda6 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 31453438464 bytes (31454 MB) Current device size: 99616333824 bytes (99617 MB) New volume size : 99616330240 bytes (99617 MB) Checking filesystem consistency ... Accounting clusters ... Space in use : 26366 MB (83.8%) Collecting resizing constraints ... Schedule chkdsk for NTFS consistency check at Windows boot time ... Resetting $LogFile ... (this might take a while) Updating $BadClust file ... Updating $Bitmap file ... Updating Boot record ... Syncing device ... Successfully resized NTFS on device '/dev/sda6'. ======================================== Move /dev/sda5 to the right and grow it from 13.67 GiB to 30.27 GiB 26:46 ( SUCCES ) calibrate /dev/sda5 00:00 ( SUCCES ) path: /dev/sda5 start: 35632233 end: 64308194 size: 28675962 (13.67 GiB) calculate new size and position of /dev/sda5 00:00 ( SUCCES ) requested start: 54524610 requested end: 118013489 requested size: 63488880 (30.27 GiB) new start: 54524610 new end: 118013489 new size: 63488880 (30.27 GiB) check filesystem on /dev/sda5 for errors and (if possible) fix them 00:08 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda5 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 14682092544 bytes (14683 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 9743 MB (66.4%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 10286 MB 0 Multi-Record : 10285 MB 128823 $MFTMirr : 5298 MB 1 Ordinary : 10595 MB 126731 You might resize at 9742360576 bytes or 9743 MB (freeing 4940 MB). Please make a test run using both the -n and -s options before real resizing! move filesystem to the right 25:50 ( SUCCES ) perform readonly test 10:34 ( SUCCES ) using internal algorithm read 28675962 sectors finding optimal blocksize read 32768 sectors using a blocksize of 128 sectors 00:02 ( SUCCES ) 32768 of 32768 read 1.78056 seconds read 32768 sectors using a blocksize of 256 sectors 00:01 ( SUCCES ) 32768 of 32768 read 0.855808 seconds read 32768 sectors using a blocksize of 512 sectors 00:01 ( SUCCES ) 32768 of 32768 read 0.729582 seconds read 32768 sectors using a blocksize of 1024 sectors 00:01 ( SUCCES ) 32768 of 32768 read 0.999657 seconds optimal blocksize is 512 sectors (256.00 KiB) read 28544890 sectors using a blocksize of 512 sectors 10:29 ( SUCCES ) 28544890 of 28544890 read 28675962 sectors read perform real move 15:16 ( SUCCES ) using internal algorithm copy 28675962 sectors finding optimal blocksize copy 32768 sectors using a blocksize of 64 sectors 00:07 ( SUCCES ) 32768 of 32768 copied 6.5577 seconds copy 32768 sectors using a blocksize of 128 sectors 00:06 ( SUCCES ) 32768 of 32768 copied 6.00697 seconds copy 32768 sectors using a blocksize of 256 sectors 00:03 ( SUCCES ) 32768 of 32768 copied 3.45753 seconds copy 32768 sectors using a blocksize of 512 sectors 00:03 ( SUCCES ) 32768 of 32768 copied 2.29627 seconds copy 32768 sectors using a blocksize of 1024 sectors 00:02 ( SUCCES ) 32768 of 32768 copied 1.91669 seconds copy 32768 sectors using a blocksize of 2048 sectors 00:01 ( SUCCES ) 32768 of 32768 copied 1.34267 seconds copy 32768 sectors using a blocksize of 4096 sectors 00:01 ( SUCCES ) 32768 of 32768 copied 1.25598 seconds copy 32768 sectors using a blocksize of 8192 sectors 00:01 ( SUCCES ) 32768 of 32768 copied 1.07902 seconds copy 32768 sectors using a blocksize of 16384 sectors 00:01 ( SUCCES ) 32768 of 32768 copied 1.03101 seconds optimal blocksize is 16384 sectors (8.00 MiB) copy 28381050 sectors using a blocksize of 16384 sectors 14:51 ( SUCCES ) 28381050 of 28381050 copied 28675962 sectors copied move partition to the right 00:01 ( SUCCES ) old start: 35632233 old end: 64308194 old size: 28675962 (13.67 GiB) new start: 54524610 new end: 83200571 new size: 28675962 (13.67 GiB) updating bootsector of ntfs filesystem on /dev/sda5 00:00 ( SUCCES ) echo c2fa3f03 | /usr/bin/xxd -r -p | /bin/dd conv=notrunc of=/dev/sda5 bs=1 seek=28 4+0 records in 4+0 records out 4 bytes (4 B) copied, 5.511e-05 s, 72.6 kB/s check filesystem on /dev/sda5 for errors and (if possible) fix them 00:08 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda5 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 14682092544 bytes (14683 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 9743 MB (66.4%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 10286 MB 0 Multi-Record : 10285 MB 128823 $MFTMirr : 5298 MB 1 Ordinary : 10595 MB 126731 You might resize at 9742360576 bytes or 9743 MB (freeing 4940 MB). Please make a test run using both the -n and -s options before real resizing! grow filesystem to fill the partition 00:00 ( SUCCES ) run simulation 00:00 ( SUCCES ) ntfsresize -P --force --force /dev/sda5 --no-action ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 14682092544 bytes (14683 MB) New volume size : 14682087936 bytes (14683 MB) Nothing to do: NTFS volume size is already OK. real resize 00:00 ( SUCCES ) ntfsresize -P --force --force /dev/sda5 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 14682092544 bytes (14683 MB) New volume size : 14682087936 bytes (14683 MB) Nothing to do: NTFS volume size is already OK. calculate new size and position of /dev/sda5 00:00 ( SUCCES ) requested start: 54524610 requested end: 118013489 requested size: 63488880 (30.27 GiB) new start: 54524610 new end: 118013489 new size: 63488880 (30.27 GiB) check filesystem on /dev/sda5 for errors and (if possible) fix them 00:09 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda5 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 14682092544 bytes (14683 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 9743 MB (66.4%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 10286 MB 0 Multi-Record : 10285 MB 128823 $MFTMirr : 5298 MB 1 Ordinary : 10595 MB 126731 You might resize at 9742360576 bytes or 9743 MB (freeing 4940 MB). Please make a test run using both the -n and -s options before real resizing! grow partition from 13.67 GiB to 30.27 GiB 00:00 ( SUCCES ) old start: 54524610 old end: 83200571 old size: 28675962 (13.67 GiB) new start: 54524610 new end: 118013489 new size: 63488880 (30.27 GiB) check filesystem on /dev/sda5 for errors and (if possible) fix them 00:08 ( SUCCES ) ntfsresize -P -i -f -v /dev/sda5 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 32506306560 bytes (32507 MB) Checking for bad sectors ... Checking filesystem consistency ... Accounting clusters ... Space in use : 9743 MB (66.4%) Collecting resizing constraints ... Estimating smallest shrunken size supported ... File feature Last used at By inode $MFT : 10286 MB 0 Multi-Record : 10285 MB 128823 $MFTMirr : 5298 MB 1 Ordinary : 10595 MB 126731 You might resize at 9742360576 bytes or 9743 MB (freeing 4940 MB). Please make a test run using both the -n and -s options before real resizing! grow filesystem to fill the partition 00:22 ( SUCCES ) run simulation 00:10 ( SUCCES ) ntfsresize -P --force --force /dev/sda5 --no-action ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 32506306560 bytes (32507 MB) New volume size : 32506302976 bytes (32507 MB) Checking filesystem consistency ... Accounting clusters ... Space in use : 9743 MB (66.4%) Collecting resizing constraints ... Schedule chkdsk for NTFS consistency check at Windows boot time ... Resetting $LogFile ... (this might take a while) Updating $BadClust file ... Updating $Bitmap file ... Updating Boot record ... The read-only test run ended successfully. real resize 00:12 ( SUCCES ) ntfsresize -P --force --force /dev/sda5 ntfsresize v2.0.0 (libntfs 10:0:0) Device name : /dev/sda5 NTFS volume version: 3.1 Cluster size : 4096 bytes Current volume size: 14682092032 bytes (14683 MB) Current device size: 32506306560 bytes (32507 MB) New volume size : 32506302976 bytes (32507 MB) Checking filesystem consistency ... Accounting clusters ... Space in use : 9743 MB (66.4%) Collecting resizing constraints ... Schedule chkdsk for NTFS consistency check at Windows boot time ... Resetting $LogFile ... (this might take a while) Updating $BadClust file ... Updating $Bitmap file ... Updating Boot record ... Syncing device ... Successfully resized NTFS on device '/dev/sda5'. ======================================== Create Logical Partition #1 (linux-swap, 2.15 GiB) on /dev/sda 00:02 ( SUCCES ) create empty partition 00:00 ( SUCCES ) path: /dev/sda7 start: 50010408 end: 54524609 size: 4514202 (2.15 GiB) set partitiontype on /dev/sda7 00:01 ( SUCCES ) new partitiontype: linux-swap create new linux-swap filesystem 00:01 ( SUCCES ) mkswap /dev/sda7 Setting up swapspace version 1, size = 2311266 kB no label, UUID=1b4f81f4-e27c-4dc4-b9a5-5241db6b7c86 ======================================== Create Logical Partition #2 (ext3, 17.80 GiB) on /dev/sda 00:09 ( SUCCES ) create empty partition 00:01 ( SUCCES ) path: /dev/sda8 start: 12691476 end: 50010344 size: 37318869 (17.80 GiB) set partitiontype on /dev/sda8 00:00 ( SUCCES ) new partitiontype: ext3 create new ext3 filesystem 00:08 ( SUCCES ) mkfs.ext3 /dev/sda8 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 1166880 inodes, 4664858 blocks 233242 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 143 block groups 32768 blocks per group, 32768 fragments per group 8160 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 Writing inode tables: 0/143 1/143 2/143 3/143 4/143 5/143 6/143 7/143 8/143 9/143 10/143 11/143 12/143 13/143 14/143 15/143 16/143 17/143 18/143 19/143 20/143 21/143 22/143 23/143 24/143 25/143 26/143 27/143 28/143 29/143 30/143 31/143 32/143 33/143 34/143 35/143 36/143 37/143 38/143 39/143 40/143 41/143 42/143 43/143 44/143 45/143 46/143 47/143 48/143 49/143 50/143 51/143 52/143 53/143 54/143 55/143 56/143 57/143 58/143 59/143 60/143 61/143 62/143 63/143 64/143 65/143 66/143 67/143 68/143 69/143 70/143 71/143 72/143 73/143 74/143 75/143 76/143 77/143 78/143 79/143 80/143 81/143 82/143 83/143 84/143 85/143 86/143 87/143 88/143 89/143 90/143 91/143 92/143 93/143 94/143 95/143 96/143 97/143 98/143 99/143100/143101/143102/143103/143104/143105/143106/143107/143108/143109/143110/143111/143112/143113/143114/143115/143116/143117/143118/143119/143120/143121/143122/143123/143124/143125/143126/143127/143128/143129/143130/143131/143132/143133/143134/143135/143136/143137/143138/143139/143140/143141/143142/143done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 33 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. mke2fs 1.40.8 (13-Mar-2008) ========================================
Thank you for the detailed bug report Jacques du Toit. I think you have discovered something important regarding the optimization algorithm. I used GParted to move a 2 GB NTFS partition around on my hard drive. Each time GParted selected a size of 256 blocks as being the optimum. In each case the algorithm stopped after benchmarking and finding that the 512 block size took slightly longer. So I manually modified the code and tried the following block sizes and timed the copy. The results showed that a size of 256 blocks was indeed SLOWER in the overall copy. Here are the test results: Block Size (x 512 bytes) 256 16384 32768 65536 Move Time (minutes) 4:05 1:35 1:33 1:31 I will do some further investigation and report back here.
After modifying the code to always perform all benchmark tests, I can see that the previous algorithm would not always select the fastest block size. In fact it appears that it would seldom select the fastest time. It is interesting to note that re-running the tests several times produce slightly different results. These anomalies would make the old algorithm favour the smaller block sizes, which as the above test shows, is incorrect. Following is the move portion of the GParted saved details file: -------------------- move filesystem to the left 00:01:44 ( SUCCESS ) using internal algorithm copy 4192902 sectors finding optimal blocksize copy 65536 sectors using a blocksize of 64 sectors 00:00:04 ( SUCCESS ) 65536 of 65536 copied 3.72721 seconds ( ERROR ) copy 65536 sectors using a blocksize of 128 sectors 00:00:03 ( SUCCESS ) 65536 of 65536 copied 3.47293 seconds ( ERROR ) copy 65536 sectors using a blocksize of 256 sectors 00:00:04 ( SUCCESS ) 65536 of 65536 copied 3.76682 seconds ( ERROR ) copy 65536 sectors using a blocksize of 512 sectors 00:00:04 ( SUCCESS ) 65536 of 65536 copied 4.25337 seconds ( ERROR ) copy 65536 sectors using a blocksize of 1024 sectors 00:00:03 ( SUCCESS ) 65536 of 65536 copied 2.85046 seconds ( ERROR ) copy 65536 sectors using a blocksize of 2048 sectors 00:00:02 ( SUCCESS ) 65536 of 65536 copied 2.1503 seconds ( ERROR ) copy 65536 sectors using a blocksize of 4096 sectors 00:00:02 ( SUCCESS ) 65536 of 65536 copied 1.78063 seconds ( ERROR ) copy 65536 sectors using a blocksize of 8192 sectors 00:00:02 ( SUCCESS ) 65536 of 65536 copied 1.5771 seconds ( ERROR ) copy 65536 sectors using a blocksize of 16384 sectors 00:00:01 ( SUCCESS ) 65536 of 65536 copied 1.49222 seconds ( ERROR ) copy 65536 sectors using a blocksize of 32768 sectors 00:00:02 ( SUCCESS ) 65536 of 65536 copied 1.45671 seconds ( ERROR ) copy 65536 sectors using a blocksize of 65536 sectors 00:00:01 ( SUCCESS ) 65536 of 65536 copied 1.4524 seconds ( ERROR ) optimal blocksize is 65536 sectors (32.00 MB) copy 3472006 sectors using a blocksize of 65536 sectors 00:01:16 ( SUCCESS ) 3472006 of 3472006 copied 4192902 sectors copied -------------------- Using the times noted in the above details file, the old algorithm would have selected an optimal block size of 128. This is because the time to copy using a block size of 256 was slightly longer (3.76682 seconds) versus the time for the block size of 128 (3.72721 seconds) The new algorithm correctly selects the fastest time based on all of the copy times. I will need to perform some more testing to ensure that the new algorithm does not introduce any new bugs prior to committing the change to the source code repository. Thank you again for bringing this problem to my attention. :-)
Thanks very much, and thank you all for producing such a high quality, free and open source product. I am often amazed at the dedication and commitment of the open source community - I don't know where you guys get the time, but I'm sure glad that you do :-) !! Take care Jacques
Thank you for your appreciation Jacques du Toit. I have completed testing of the enhanced algorithm and have not discovered any new problems. This change has been committed to the gnome SVN repository for inclusion in the next version of GParted (0.3.9). Closing this bug.
*** Bug 438574 has been marked as a duplicate of this bug. ***
*** Bug 517950 has been marked as a duplicate of this bug. ***
*** Bug 566381 has been marked as a duplicate of this bug. ***