1

Topic: Wanted: hand-holding for W2K3 x64 changing allocations/partitions

I have a W2k3 x64 production server with a 136GB HDD with the following partitions:

C: = 12GB     11% free
D: = 123GB    82% free

I'm running out of space on C and need to steal some of the space from D to give to C. I've been reading/preparing and I think I need to do the following:

1. Backup all data on server. (I was going to use Clonezilla and make an image of it)
2. Change the partition for D to free up some space between C and D
3. Change the partition for C to use that free space between C and D

I'm quite nervous about this and wanted to know if someone could take a little time to assist me; especially if they've done these actions with this configuration before. I've never used gparted before and want the added security and confidence of someone who has been there before.

Thank you!

2

Re: Wanted: hand-holding for W2K3 x64 changing allocations/partitions

This is the usual way to follow.

Some tips:
1) Often that D: partition is a logical partition located in another extended one. You can check it in GParted, because Linux gives numbers 1-4 to the 4 primary partitions and numbers 5, 6, ... to the logical ones. In this case, you have partitions named as /dev/sda1 (the system partition), /dev/sda2 (extended) and /dev/sda5 (the D: partition). If so, you need to shrink /dev/sda5 first, shrink the extended partition /dev/sda2 in a second step to leave the unallocated space outside and in a 3rd step grow the system partition to take that unallocated space.

2) It is better to go step by step. GParted allows to schedule many operations, however I advice to go step by step, reboot to the operating system 2 times, check to see that everything is as expected and then proceed to the next step. I know that this takes more time. However, partitioning is a task very special, normally done at most a few times in the lifetime of a system. It is potentially "dangerous", because an error can make the system unbootable, damage the partition table, damage the filesystem (worse). Power problems or hardware failure are potential sources of errors. Going step by step allows more control.

3) You have to be careful to not change the start sector of the C: partition. This manner, you don't have to expect unbootable system problems.
It is good to keep noted the exact partition size and position before any operation. You can check these partition details by the Information menu (available from the right button menu, too).
After resizing a system partition and rebooting into the O.S., it is usual to expect the system checking the filesystem and "repairing". You have to leave it complete this check and reboot. You probably will see messages about "new device found"... This is normal, too. Login and check if everything is as expected.
A few times, the partition is grown but the filesystem isn't (reported for many resizing software tools). In this case, you see the partition manager in mswindows management show the new size, but the explorer gives the old size. In that case, you can reboot GParted live, select the partition under question and run the "Check" command. This adjusts the filesystem.

4) It is better to defragment the partitions (with the operating system defrag tools) before proceeding.

5) Shrinking a partition from the start point is usually more time consuming that moving the end point. Hopefully, you have a lot of free space, just 18% of data. Growing a partition by moving the end point to the right is usually a lot faster.

6) Of course, backup is a must, especially for a professional system. Even a bad connector of the hard drive can cause a resizing failure, as it was sometimes reported to this forum.
In case of dubt, you can post here a screenshot of the GParted screen, and the output of the command
sudo fdisk -lu
in the terminal window. This gives data on the partition table, with sector precision.

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

3

Re: Wanted: hand-holding for W2K3 x64 changing allocations/partitions

Thank you so much!! I was going to wait to post with my results, but thought I should thank you sooner. May attempt this today. Thank you again!!

4

Re: Wanted: hand-holding for W2K3 x64 changing allocations/partitions

I forgot to mention (but perhaps you already know) that defrag in mswindows needs at least 15% free disk space to work. This is true for older versions, up to win 2000 and xp; I don't know if it is mandatory for your version. Anyway, every time I tried to defragment a partition with very small free space, the operation took long and was unefficient. I usually try to temporarily move some data elsewhere (however this isn't always possible, especially in the system volume of a server).

I don't know if other defrag software is more efficient (in case you already have any installed).

In any case, defrag isn't mandatory for the resizing code. It helps in case of complicated file trees.

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