1 Topic by Chumley

  • Chumley
  • New member
  • Offline
  • Registered: 2006-08-07
  • Posts: 5

Topic: My experience with GPartEd...heartstopping moments yet finally love :)

Heya All,

First off, let me say THIS TOOL ROCKS!! Thanks to everyone involved with its creation and support.

I am posting this to detail my experience with GPartEd, which was NOT trouble free nor without a few moments I would describe as "heartstoppers" in order to allow others to get an idea of what to expect.

I am a professional IT Consultant, owner of my own business. I have a client, a publishing house, that had a major server with a common issue: It came from the OEM (Gateway in this case) with a too-small system partition. Coming in late on this server, the bad was done and the server needed to either be rebuilt, or have its partitions resized. As this is a major provider of services (web based) to clients of my client and had numerous "custom" things done to it with little or no documentation, I chose to resize the partitions with GPartEd. Note that the client has a complete in-house backup solution which I could also use to rebuild the server, so I did have an "ace-in-the-hole" so to speak should it come to that.

The hardware:

Gateway 975 series, 3 HDD in RAID 5 on an LSI MegaRAID controller

The OS:

Windows 2K3 SP2

The Partitions:

C:\ 17.5GB with 140MB free (NTFS)

D:\ 255GB with 215GB free (NTFS)

The Software:

GPartEd LiveCD version 0.3.4-8 (latest as of this writing)

The Task:

Take 40GB off of drive D: and put it onto drive C:

Part 1: Install Safety Net
I am old and have learned my lessons. I will NOT operate without a net! Therefore I make a full and complete backup of the server immediately before I operate on it. I make sure my Disaster Recovery CD's and files are 100% good-to-go. I also did a defrag on drive D:, but since drive C: has only 140MB free Windows won't defrag it. Gotta go with what you got sometimes and also, I am making C: bigger, not smaller, so the data on it should be untouched I figure...so I am not afeared o' that!

Part 2: Does it boot and recognize the drives/partitions?
I downloaded the LiveCD image and created the CD from it. Tried to boot off it but was unsuccessful. Tried various things (hit F10 and choose "CD-ROM" as the boot device, etc) but no joy until I went into the BIOS and disabled all other choices, i.e. I forced the system to boot from the CD. It booted off an OEM Windows install disk (as a test) but not from the LiveCD until I forced it...wierd but OK, it boots. During the boot sequence I do note the LSI driver being installed...good. Scans the disks and voila' there they are, my partitions. So far so good.

Part 3: Set up the job (heartstopping moment #1):
I set up the job: Resize D: to 215GB, Move it "to the right", resize the extended partiton to free up space "between" it and drive C:, resize drive C: to its new size of 57.5GB. I Followed the instructions found in the "Tips" area of the documentation web page. Went through it religiously and missed no part of it. Hit "Apply" and answered "yes" to the warning...its off to the races!
     Heartstopping moment #1: ERROR!! ERROR!! Danger Will Robinson (told ya I was old!)!!  The first operation errors out. I go through each step of it waiting to see the hammer has fallen but no, its just that, in my endeavour to boot off the CD, I had powered off the server before it booted Windows all the way. This leaves the file journal in an unclean state. Luckily for me this cool tool does test runs before commiting, and so it failed on a test run...sweet! A setback and my fault completely but still, easily solved by booting to Windows and shutting it down cleanly. Now we try again!

Part 4: Do over! (heartstopping moment #2):
I again set the job up, going through each step from the "Tips" page religiously. I again hit "Apply" and off it goes....and goes...and goes....and goes...It took 16 HOURS to resize D: drive and move it "to the right". I started this on 7/11/07 at 18:00 EST and it went until 10:00 7/12/07 EST. Yikes! But it finally finished that step (operation 2 of 4) and went on to resize the extended partiton...operation 3 of 4 is done...then it went on to resize the C: (primary) partition...it went trough its steps, gets to the "real resize"  and then...
        Heartstopping moment #2: BOOOOOMMM...the GParted window just poofed away. Now I've used this tool before for minor ops, and its never just closed on its own. It always finishes, rescans the drives, and shows you the new sizes. This seems definitely an abend. Hmmm...I sit a minute and do nothing, hoping maybe its a video-business thing and the window will return...nope. I open a terminal and check the processes, nothing with any obvious relation to GParted is running. It definitely seems to have abended. So finally I click up on the icon and start a new instance of it. It scans the drives and comes back with exactly the partitoning I wanted it to be. I hope its cool because I could lose D: drive and restore from tape much quicker than having to do the whole system....I grit my teeth and reboot...

Part 4: Reboot and wierdness abounds...
I reboot the system the proper way (eject and reboot) but it doesn't really go down all the way. I wait and wait for it to finally turn off after I did the control-d thang but it never does. I finally (i.e. after 15 minutes) power it off/on. It reboots and does the expected file system checks on drive D:, but not C:. I let it continue anyway and it boots normally to Win2K3. I then go to "My Computer" and it shows C: as 17.5GB, and D: as 215GB. So it looks like the op on drive C: failed but didn't hose the content or partiton. I look in Windows Disk Manager and it says that drive C: is 57.5GB...OK thats wierd too....So I reboot again hoping it will do its checks on drive C: this time...no joy. Same results, no checks to any drive and C: is 17.5Gb in "My Computer" yet 57.5GB in "Disk Manager". I then decided to force a checkup on drive C:, so I go into the drive tools and tell it to check C:. I reboot and it does the check, with all 3 checks seeing to be without error. I go into "My Computer" and "Disk Manager" and it is the same, i.e they are not in synch. Yikes...hrmm...what to do, what to do...

Part 5: Do over on drive C:
So I finally decide to boot the thing on GPartEd and see if maybe I've overlapped or something, though I did use exact numbers back in steps 3 and 4, i.e. I took 40960MB (40GB) off Drive D: and put 40960MB onto drive C:. Well, I boot it up, it scans the drives, and says that C: is indeed 57.5GB AND there is 7.5MB of unallocated space between the two partitions. ARGH! I've forgotten the 8MB "buffer" between drives! Have you ever installed Windows XP or server? It ALWAYS leaves 8MB "unused" even if you tell it to use all the space for the partiton. I don't know the exact why to this, but I know it does it and I forgot to allow for it...grrr...my bad AGAIN. Sheesh! So I resize drive C:, taking 957MB off the end (yeah, its overkill but I wanted a definite space between the two "just in case" and I ain't sweating it). This time GPartEd does it the way it should, ending properly.

Part 6: Final Reboot?
  I reboot again and it checks drive C: as expected, which just makes me all warm and fuzzy inside. I love everybody, man....
Sure enough, all is well. Drive C: is 34.6GB, drive D: is 215GB, and there is even 957MB showing as unallocated in Disk Manager. As I said, I love everybody, man smile

So thats my story using GPartEd. I rather caused my own troubles (I think) and heartstopping moments by not having a clean journal and not leaving the 8MB between partitions. In the future I will ALWAYS leave at least 20MB between NTFS partitions (and probably all others as such space is tres cheap). I hope anyone reading this will learn from my mistakes and also have an idea of the TIME it took do it. That was the major surprise for me, that it took 16 hours to move 215GB "to the right". Sure I expected a long time, but 16 hours...whew! If I had to do this again, I might just choose to rebuild it using the disaster recovery procedures, as that would have been much faster. Still though, disaster recovery requires a drive reformat which means the data is LOST until restored...and what if the tape is bad (even though verified after backup)? Things to think about should the situation arise again...gonna take that case by case smile

Good luck all, and S! (Salute!)

Chumley

2 Reply by class413

  • class413
  • Moderator
  • Offline
  • Registered: 2007-05-25
  • Posts: 2,376

Re: My experience with GPartEd...heartstopping moments yet finally love :)

Dear Chumley,

Your post is a real course for anybody. Very important, you took backup, what all experienced administrators do. Unfortunately, people learn only after the disaster...

In your case, I would consider the following steps:
1. Shrink D: to the minimum, around 40GB.
2. Reboot to win + check and adjust the filesystem.
3. Move the D: just after the actual end and expand it up to the end of the disk. Since there is no overlap, it would be much faster.
4. Reboot to win + check and adjust the filesystem.
5. Expand the C: system partition in the unallocated space.
6. Reboot to win + check and adjust the filesystem.

It makes more steps and some more work by the administrator, but I'd like this idea because I could have a closer control over the entire process. Furthermore, as we know very well, any partition job is potentially dangerous, so we have to go slowly, thinking at least twice everything and have a good working U.P.S.! I hope your server was equipped wink

*** It is highly recommended to backup any important files before doing resize/move operations. ***

3 Reply by Chumley

  • Chumley
  • New member
  • Offline
  • Registered: 2006-08-07
  • Posts: 5

Re: My experience with GPartEd...heartstopping moments yet finally love :)

Class413,

Thanks for the reply.

I see what you are getting at, that moving the 40GB would be easier/faster than the 215GB I did move. Do you have any experience in moving 40GB of data, i.e. how long would it take? I realize that the drive type and other factors would have a large impact on this also, but I am wondering what people's experiences with time/data are. Maybe I should start a thread about that..ask people for the type of hard drive (Sata, IDE, SCSI, etc), amount of data moved, and time it took. An impromtu database if you will that professional users such as myself could use to "guesstimate" the time necessary to do a particular operation. Certainly it could only be used for planning but it would be better than nothing.

S!

Chum

4 Reply by class413

  • class413
  • Moderator
  • Offline
  • Registered: 2007-05-25
  • Posts: 2,376

Re: My experience with GPartEd...heartstopping moments yet finally love :)

I have no such personal experience, I tell it rather "intuitively", from my older experience on programming (data moving) and on the manner various defragmentation programs seem to work in windows (like windows defrag, a similar Norton program ... ). It takes quite long to make some empty space by moving actual data in any other empty part of the disk in order to put there specific data. Just moving a big contiguous data block to another contiguous empty place is much faster than making room and then copying or moving it by small blocks. I don't know in detail how Parted or the special ntfs-manipulation tool works, but I wouldn't be surprised if I learned that it goes sector by sector in that case. I did never experiment about that (I have an old computer with rather small RAM to support the GUI).

Of course, the disk and controller technology is responsible for a part of the time, but I think that it could never be 1/5 or 1/10 x 16 hours just by going from IDE to SCSI (except RAM-disks, of course wink ). Another factor is the disk cache, but I don't know if using the disk cache is safe for this kind of work.

By the way, I always remember what I read in an old book from the era of 8 bit and early 16 bit microcomputers about the design of the "small business" systems at the time: to find how big disk space we need, we must calculate space for the system, the various administration and maintenance tools, the application software, the data base files that will be created, all this largely to the safe side, and finally double the sum of the above. This will be the least!

*** It is highly recommended to backup any important files before doing resize/move operations. ***