1 (edited by TexasDayLily 2009-05-08 19:40:20)

Topic: [SOLVED]Windows and Gparted disagree on /dev/hda1 (C:) size --Help

I seem to have a problem where windows thinks my C: (XP system) partition is 25Gib and Gparted think it is 27.34Gib.

Here is the results from a current fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xf868f868

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        3569    28667961    7  HPFS/NTFS
/dev/sda2            3570        7294    29921062+   5  Extended
/dev/sda5            3571        3701     1052257+   7  HPFS/NTFS
/dev/sda6            3702        5224    12233466    7  HPFS/NTFS
/dev/sda7            5225        5355     1052226    b  W95 FAT32
/dev/sda8            5356        5486     1052226   82  Linux swap / Solaris
/dev/sda9            5487        5617     1052226   83  Linux
/dev/sda10           5618        5650      265041   83  Linux
/dev/sda11           5651        5781     1052226   83  Linux
/dev/sda12           5782        6304     4200966   83  Linux
/dev/sda13           6305        6794     3935893+  83  Linux
/dev/sda14           6958        6990      265041   83  Linux

In December 08 I had the following fdisk saved.

linux:/home/linux # fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xf868f868

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        5222    41945683+   7  HPFS/NTFS
/dev/sda2            5223        7296    16659405    5  Extended
/dev/sda5            5223        5223        8001    7  HPFS/NTFS
/dev/sda6            5224        5224        8001    7  HPFS/NTFS
/dev/sda7            5225        5355     1052226    b  W95 FAT32
/dev/sda8            5356        5486     1052226   82  Linux swap / Solaris
/dev/sda9            5487        5617     1052226   83  Linux
/dev/sda10           5618        5650      265041   83  Linux
/dev/sda11           5651        5781     1052226   83  Linux
/dev/sda12           5782        6304     4200966   83  Linux
/dev/sda13           6305        6794     3935893+  83  Linux
/dev/sda14           6795        6826      257008+  83  Linux

I can't account for the unallocated space between /dev/sda13 and /dev/sda14, but /dev/sda14 is /var for OpenSuse 11.1. 

Window Reports the following sizes for c:, p:, and u: through the Disk Properties and Chkdsk (I added calculations for Kib, Mib, and Gib based on byte counts)

c: Capacity                
26,847,277,056  Bytes       
26847277056  Bytes            
26218044 Kib            
25603.55859375 Mib      
25.003475189208984 Gib  
25.0 GB                 

Chkdsk Capacity                
26218044 KB             


P: Capacity                
1,077,506,048  Bytes          
1077506048  Bytes             
1052252 Kib             
1027.58984375 Mib       
1.0035057067871094 Gib  
1.00 GB                 

Chkdsk Capacity               
1052252 KB             


U: 12,527,063,040  Bytes          
12527063040  Bytes            
12233460 Kib            
11946.73828125 Mib      
11.666736602783203 Gib  
11.6 GB                 

Chkdsk Capacity                
12233460 KB             

I was following a process of shrinking C: and growing P: and U: when an error.  Error was

Grow /dev/hda1 from 25.00 GiB to 27.34 Gib.  I looked for more details but didn't see anything but that error.

The procedure I followed to get to this point was to shrink C: by 15Gib.
Change the extended partition to include the 15Gib.
Move  P: to the beginning to the extended partition again.
Resize P to be 1Gib. 
Move U: to the start of the unallocated space grow to take remaining 14Gib.

I took all these steps one at a time and each succeeded.  I then attempted to boot into safe mode with windows.
The boot  paused when loading the kernel and then restarted.  I figured the 700 something Mib free space I left in the partition was inadequate  so I attempted to get  more space for c: temporarily.  I really didn't care to be exact because I knew that I was going to move file to U and then resize C, P, and U again until I was through moving files off C:.  I also had backups in Norton Ghost, but I didn't want to use backups because I'd have to put the partitions back to the sizes they were to do the restore.

At that point I shrunk and moved U to 11.67Gib so that the free space was before the partition.
I then moved P to be right before U with the free space before it.
I then moved the free space out of the extended partition.
At that point I attempted to grow /dev/hda1 (C:) from 25.00 GiB to 27.34 Gib.

The previous steps I took to make the space all worked sucessfully.   I was able to boot into safe mode even though I had the error and was able to chkdsk /r the P: and U: partitions which had been resized.  I had to reboot to chkdsk /r /f C:.  Near the end of the process chkdsk started to post the same error for every cluster.  The message went something like error unable to reallocate bad cluster no more room on disk for cluster #...    I saw hundreds off these roll by before noticed that the cluster numbers were increasing and seemed to have potentially gone beyond the size of the partition.  I eventually decided to power off the machine.   

While exploring what to do next, I booted into OpenSuse 11.1 (I also have OpenSuse 11.0) and tried a few things.  One of the things I tried was  ntfsfix /dev/sda1.  I also forced a mount of C: when I noticed that it wasn't mounted because the chkdsk had failed and it was considered dirty.  I was able to browse it fine.   I eventually ran a chkdsk from a Vista-Recovery CD which worked.   I also ran a chkdsk accidentally by booting XP which fixed some problems very early in the boot process and then gave me a windows login.  I shutdown and rebooted into safemode and proceeded to discover that for some reason my system was now ok. 

After running for a few days I finally noticed the anomalies in the Gib data between the linux gparted and chkdsk.  I need to fix the partition table or whatever is wrong because I'm not finished changing my partitions.   I  would appreciate some direction on how to resolve where the problem is and how to fix it.

I have some current screen pictures for Gparted and Windows Disk Management if it would help.  There is an unallocated 7.84Mib area immediatly following the extended partition which I didn't intend to be  there.

2

Re: [SOLVED]Windows and Gparted disagree on /dev/hda1 (C:) size --Help

Hello TexasDayLily,

partition sda1 was obviously logically not resized. It often helps, if you repeat the last step, i.e. shrink sda1 back to 25 GiB and then resize it again to 27,34 GiB. Let "chkdsk /f /r" run twice, and the problem is probably solved.

There is an unallocated 7.84Mib area immediatly following the extended partition which I didn't intend to be  there.

This unusable space exists due to cylinder alignment of volume partitions. One cylinder contains 8225280 Bytes = 7.844 MiB. If there is one byte less, the space is not usable.

Regards
cmdr

3 (edited by TexasDayLily 2009-05-07 20:37:43)

Re: [SOLVED]Windows and Gparted disagree on /dev/hda1 (C:) size --Help

I have resized it back to 25GiB and it seems to have worked.  I used 25603 as the number of megabytes and hoped that it would take care of the decimal portion (.55859375) appropriately.   Windows now reports exactly the same number of bytes as it had before after rebooting twice running and running chkdsk.  I'm going to run chkdsk again just in case. 

At this point I actually need to shrink the partition further (down about 8GiB) rather than increasing it.  I had increased it before simply because I thought that was why the first boot into safe mode failed and attempted to restart.  I've been able to move about 8 Gib of data off C to the U partition so now I'm ready to shrink it some more.

My concern is that windows and gparted are not exactly in agreement as to the C partition size.   They both report 25 GiB but there is a lot of room for error when using Gib units.   If I shrink it further will it work if they are not exactly in agreement to the exact number of bytes.  Here are the details I captured.  After looking at them there are a lot more details that what I was able to see by expanding the command once.  It appears that the number of bytes do not agree with the number reported in windows which is  26,847,277,056.

Shrink /dev/hda1 from 27.34 GiB to 25.00 GiB  00:00:23    ( SUCCESS )
         
calibrate /dev/hda1  00:00:03    ( SUCCESS )
         
path: /dev/hda1
start: 63
end: 57335984
size: 57335922 (27.34 GiB)
calculate new size and position of /dev/hda1  00:00:00    ( SUCCESS )
         
requested start: 63
requested end: 52436159
requested size: 52436097 (25.00 GiB)
new start: 63
new end: 52436159
new size: 52436097 (25.00 GiB)
check file system on /dev/hda1 for errors and (if possible) fix them  00:00:09    ( SUCCESS )
         
ntfsresize -P -i -f -v /dev/hda1
         
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26847277568 bytes (26848 MB)
Current device size: 29355992064 bytes (29356 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 16309 MB (60.7%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 23577 MB 0
Multi-Record : 26407 MB 82522
$MFTMirr : 2579 MB 1
Compressed : 16353 MB 68192
Ordinary : 26231 MB 195
You might resize at 16308109312 bytes or 16309 MB (freeing 10539 MB).
Please make a test run using both the -n and -s options before real resizing!
shrink file system  00:00:00    ( SUCCESS )
         
run simulation  00:00:00    ( SUCCESS )
         
ntfsresize -P --force /dev/hda1 -s 26847281663 --no-action
         
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26847277568 bytes (26848 MB)
Current device size: 29355992064 bytes (29356 MB)
New volume size : 26847277568 bytes (26848 MB)
Nothing to do: NTFS volume size is already OK.
real resize  00:00:00    ( SUCCESS )
         
ntfsresize -P --force /dev/hda1 -s 26847281663
         
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26847277568 bytes (26848 MB)
Current device size: 29355992064 bytes (29356 MB)
New volume size : 26847277568 bytes (26848 MB)
Nothing to do: NTFS volume size is already OK.
shrink partition from 27.34 GiB to 25.00 GiB  00:00:01    ( SUCCESS )
         
old start: 63
old end: 57335984
old size: 57335922 (27.34 GiB)
new start: 63
new end: 52436159
new size: 52436097 (25.00 GiB)
check file system on /dev/hda1 for errors and (if possible) fix them  00:00:09    ( SUCCESS )
         
ntfsresize -P -i -f -v /dev/hda1
         
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26847277568 bytes (26848 MB)
Current device size: 26847281664 bytes (26848 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 16309 MB (60.7%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 23577 MB 0
Multi-Record : 26407 MB 82522
$MFTMirr : 2579 MB 1
Compressed : 16353 MB 68192
Ordinary : 26231 MB 195
You might resize at 16308109312 bytes or 16309 MB (freeing 10539 MB).
Please make a test run using both the -n and -s options before real resizing!
grow file system to fill the partition  00:00:01    ( SUCCESS )
         
run simulation  00:00:01    ( SUCCESS )
         
ntfsresize -P --force /dev/hda1 --no-action
         
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26847277568 bytes (26848 MB)
Current device size: 26847281664 bytes (26848 MB)
New volume size : 26847277568 bytes (26848 MB)
Nothing to do: NTFS volume size is already OK.
real resize  00:00:00    ( SUCCESS )
         
ntfsresize -P --force /dev/hda1
         
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/hda1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 26847277568 bytes (26848 MB)
Current device size: 26847281664 bytes (26848 MB)
New volume size : 26847277568 bytes (26848 MB)
Nothing to do: NTFS volume size is already OK.

========================================

4 (edited by cmdr 2009-05-08 12:07:40)

Re: [SOLVED]Windows and Gparted disagree on /dev/hda1 (C:) size --Help

Hello Texas DayLily,

My concern is that windows and gparted are not exactly in agreement as to the C partition size.   They both report 25 GiB but there is a lot of room for error when using Gib units.

Your concern is unsubstantiated.  If you shrink a NTFS partition, the involved programs have always to resize on a physical (sectors) AND a logical (filesystem) basis, whereas on growing, you can separate these two necessary steps without corrupting the system totally. Keep in mind, that you need several hundred Megabytes of free space to maintain a running Windows system.

Good luck
cmdr

5

Re: [SOLVED]Windows and Gparted disagree on /dev/hda1 (C:) size --Help

Furthermore, the windows defrag tool doesn't even work with less than 15% free space. Running a system with very little free disk space can lead to strange and unexpected things. Some programs don't work properly, often downloads fail with no apparent reason. A lot of friends had such problems, myself too (when running win2000 on a 36GiB hard drive with 1 GiB free).
Remember that the temporary internet files and deleted files can take a lot of space.

The Linux file systems like ext2 or ext3 don't suffer so much because they keep a part reserved for the system. However, fragmentation could affect them too in very small free %.

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

6

Re: [SOLVED]Windows and Gparted disagree on /dev/hda1 (C:) size --Help

I was able to further shrink the system volume successfully.  Thanks for the help.