1 Topic by dlcarrier

  • dlcarrier
  • New member
  • Offline
  • Registered: 2008-12-08
  • Posts: 1

Topic: Seven hour test -- is it supposed to work this way?

I just upgraded my RAM and, in order for suspend-to-disk to function correctly, I need to shrink my home partition by just over 4 GB and expand the swap partition into the empty space.  This means shrinking the the home partition from the beginning, not from the end.  The way this is performed is by shrinking the partition then moving it closer to the 'end' of the drive.  for a ~675 GB partition this can take a while, and this is understandable.  I have performed this before, but I did not touch the computer for days after I had told it to start, so I didn't get to see how long it took.  This same operation is running on more recently upgraded computer as a write this, and it will be running all night.  I started it this morning hoping it would be done the same day.  The total time needed to move the partition is about 10.5 hours, so this would be doable, if GParted didn't just spend the last seven hours performing a "readonly test" on my drive.  (See the image at the end of this post.)  It just read 1413750216 blocks, at 512 bytes each, for a total of 674.13 GB, about the size of the partition it will be moving, as part of the "readonly test".

Is this normal?  Is this test performed by GParted, or is parted performing it?  Is it necessary?  Is there a way to prevent it in the future?  Should I submit a bug report?  Here is a screenshot of GParted's actions:
http://www.daisyct.org/gparted/7_hour_test.png

Thank you for any suggestions,
David Carrier

P.S.  This is being performed on Ubuntu with an x86_64 SMP 2.6.27-9-generic kernel and GParted version 0.3.8-1ubuntu2.

2 Reply by gedakc (edited by gedakc 2008-12-08 18:09:23)

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: Seven hour test -- is it supposed to work this way?

GParted 0.3.8 contained a bug in the optimal block size algorithm.
http://bugzilla.gnome.org/show_bug.cgi?id=546423

From the screen shot, I see that GParted used a block size of 256 sectors for the "read-only" test.  This would cause a very slow copy on a fast computer.  Since you state you are using an x86_64 SMP kernel, I suspect you have fairly fast computer with at least 7200RPM drives and lots of RAM.  :-)

If I recall, a read-only scan of the drive is performed to check for any bad sectors.  If bad sectors exist, it would not be wise to move the partition.  Of course to know for sure requires checking the source code, which hopefully I can do soon.

As a general rule, I would recommend using the latest GParted version.  Currently GParted 0.4.1 is available on the Testing GParted LiveCD.

dlcarrier wrote:

Is this test performed by GParted, or is parted performing it?

GParted is performing the test.

dlcarrier wrote:

Is this normal?  Is it necessary?  Is there a way to prevent it in the future?  Should I submit a bug report?

If you submit a bug report, the process of discovery can be better tracked.