After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 601574 - ERROR: Current NTFS volume size is bigger than the device size!
ERROR: Current NTFS volume size is bigger than the device size!
Status: RESOLVED NOTGNOME
Product: gparted
Classification: Other
Component: application
0.4.8
Other Linux
: Normal major
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
: 602067 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-11-11 17:14 UTC by Curtis Gedak
Modified: 2009-12-05 21:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Dangerous script to test problem resizing partition (10.50 KB, application/x-sh)
2009-11-15 16:32 UTC, Curtis Gedak
Details

Description Curtis Gedak 2009-11-11 17:14:29 UTC
Following is the bug description and gparted_details.htm log file copied from this post in the GParted forum:
http://gparted-forum.surf4.info/viewtopic.php?pid=21802

Bug report follows:
------------------


Hi Guys, I was just trying to adjust the size of one of mi partitions and something has apparently gone wrong. If you can help you are welcome! I'm not an expert and besides all warnings and advices I haven't done a backup of my information (I know what you would think of me) but I'm in real trouble. yikes

Thank you very much in advance!

THE LOG...

GParted 0.4.8

Libparted 1.9.0
Move /dev/sda5 to the right and shrink it from 801.36 GiB to 600.00 GiB  07:52:27    ( ERROR )
        
calibrate /dev/sda5  00:00:02    ( SUCCESS )
        
path: /dev/sda5
start: 272960478
end: 1953525167
size: 1680564690 (801.36 GiB)
calculate new size and position of /dev/sda5  00:00:00    ( SUCCESS )
        
requested start: 695229003
requested end: 1953520064
requested size: 1258291062 (600.00 GiB)
new start: 695228940
new end: 1953520064
new size: 1258291125 (600.00 GiB)
check file system on /dev/sda5 for errors and (if possible) fix them  00:00:06    ( SUCCESS )
        
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: 860449120768 bytes (860450 MB)
Current device size: 860449121280 bytes (860450 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 470842 MB (54.7%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 327817 MB 0
Multi-Record : 555217 MB 115146
$MFTMirr : 1 MB 1
Compressed : 554271 MB 78838
Ordinary : 556102 MB 115123
You might resize at 470841589760 bytes or 470842 MB (freeing 389608 MB).
Please make a test run using both the -n and -s options before real resizing!
shrink file system  00:00:10    ( SUCCESS )
        
run simulation  00:00:04    ( SUCCESS )
        
ntfsresize -P --force /dev/sda5 -s 644245055999 --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: 860449120768 bytes (860450 MB)
Current device size: 860449121280 bytes (860450 MB)
New volume size : 644245049856 bytes (644246 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 470842 MB (54.7%)
Collecting resizing constraints ...
Needed relocations : 0 (0 MB)
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:00:06    ( SUCCESS )
        
ntfsresize -P --force /dev/sda5 -s 644245055999
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda5
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 860449120768 bytes (860450 MB)
Current device size: 860449121280 bytes (860450 MB)
New volume size : 644245049856 bytes (644246 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 470842 MB (54.7%)
Collecting resizing constraints ...
Needed relocations : 0 (0 MB)
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'.
You can go on to shrink the device for example with Linux fdisk.
IMPORTANT: When recreating the partition, make sure that you
1) create it at the same disk sector (use sector as the unit!)
2) create it with the same partition type (usually 7, HPFS/NTFS)
3) do not make it smaller than the new NTFS filesystem size
4) set the bootable flag for the partition if it existed before
Otherwise you won't be able to access NTFS or can't boot from the disk!
If you make a mistake and don't have a partition table backup then you
can recover the partition table by TestDisk or Parted's rescue mode.
shrink partition from 801.36 GiB to 600.00 GiB  00:00:01    ( SUCCESS )
        
old start: 272960478
old end: 1953525167
old size: 1680564690 (801.36 GiB)
new start: 272960478
new end: 1531251602
new size: 1258291125 (600.00 GiB)
check file system on /dev/sda5 for errors and (if possible) fix them  00:00:04    ( SUCCESS )
        
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: 644245049856 bytes (644246 MB)
Current device size: 860449121280 bytes (860450 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 470835 MB (73.1%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 327817 MB 0
Multi-Record : 555217 MB 115146
$MFTMirr : 1 MB 1
Compressed : 554271 MB 78838
Ordinary : 556102 MB 115123
You might resize at 470834991104 bytes or 470835 MB (freeing 173411 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:09    ( SUCCESS )
        
run simulation  00:00:05    ( SUCCESS )
        
ntfsresize -P --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: 644245049856 bytes (644246 MB)
Current device size: 860449121280 bytes (860450 MB)
New volume size : 860449116672 bytes (860450 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 470835 MB (73.1%)
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:00:04    ( SUCCESS )
        
ntfsresize -P --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: 644245049856 bytes (644246 MB)
Current device size: 860449121280 bytes (860450 MB)
New volume size : 860449116672 bytes (860450 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 470835 MB (73.1%)
Collecting resizing constraints ...
WARNING: Every sanity check passed and only the dangerous operations left.
Make sure that important data has been backed up! Power outage or computer
crash may result major data loss!
Are you sure you want to proceed (y/[n])? 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'.
calculate new size and position of /dev/sda5  00:00:00    ( SUCCESS )
        
requested start: 695228940
requested end: 1953520064
requested size: 1258291125 (600.00 GiB)
new start: 695228940
new end: 1953520064
new size: 1258291125 (600.00 GiB)
check file system on /dev/sda5 for errors and (if possible) fix them  00:00:05    ( SUCCESS )
        
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: 860449116672 bytes (860450 MB)
Current device size: 860449121280 bytes (860450 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 470842 MB (54.7%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 327817 MB 0
Multi-Record : 555217 MB 115146
$MFTMirr : 1 MB 1
Compressed : 554271 MB 78838
Ordinary : 556102 MB 115123
You might resize at 470841589760 bytes or 470842 MB (freeing 389608 MB).
Please make a test run using both the -n and -s options before real resizing!
move file system to the right  07:51:48    ( SUCCESS )
        
perform read-only test  02:26:35    ( SUCCESS )
        
using internal algorithm
read 1258291125 sectors
finding optimal blocksize
        
read 65536 sectors using a blocksize of 128 sectors  00:00:03    ( SUCCESS )
        
65536 of 65536 read
3.01886 seconds
read 65536 sectors using a blocksize of 256 sectors  00:00:03    ( SUCCESS )
        
65536 of 65536 read
3.70014 seconds
read 65536 sectors using a blocksize of 512 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 read
1.43703 seconds
read 65536 sectors using a blocksize of 1024 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
1.10518 seconds
read 65536 sectors using a blocksize of 2048 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
1.01409 seconds
read 65536 sectors using a blocksize of 4096 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
0.745188 seconds
read 65536 sectors using a blocksize of 8192 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
0.909588 seconds
read 65536 sectors using a blocksize of 16384 sectors  00:00:00    ( SUCCESS )
        
65536 of 65536 read
0.678442 seconds
read 65536 sectors using a blocksize of 32768 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
0.599121 seconds
read 65536 sectors using a blocksize of 65536 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
0.681358 seconds
optimal blocksize is 32768 sectors (16.00 MiB)
read 1257635765 sectors using a blocksize of 32768 sectors  02:26:21    ( SUCCESS )
        
1257635765 of 1257635765 read
1258291125 sectors read
perform real move  05:25:13    ( SUCCESS )
        
using internal algorithm
copy 1258291125 sectors
finding optimal blocksize
        
copy 65536 sectors using a blocksize of 64 sectors  00:00:04    ( SUCCESS )
        
65536 of 65536 copied
4.10719 seconds
copy 65536 sectors using a blocksize of 128 sectors  00:00:04    ( SUCCESS )
        
65536 of 65536 copied
3.84044 seconds
copy 65536 sectors using a blocksize of 256 sectors  00:00:05    ( SUCCESS )
        
65536 of 65536 copied
4.98139 seconds
copy 65536 sectors using a blocksize of 512 sectors  00:00:05    ( SUCCESS )
        
65536 of 65536 copied
4.77386 seconds
copy 65536 sectors using a blocksize of 1024 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
2.7315 seconds
copy 65536 sectors using a blocksize of 2048 sectors  00:00:03    ( SUCCESS )
        
65536 of 65536 copied
2.87319 seconds
copy 65536 sectors using a blocksize of 4096 sectors  00:00:03    ( SUCCESS )
        
65536 of 65536 copied
2.41651 seconds
copy 65536 sectors using a blocksize of 8192 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
2.02755 seconds
copy 65536 sectors using a blocksize of 16384 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 copied
1.61813 seconds
copy 65536 sectors using a blocksize of 32768 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
1.49475 seconds
copy 65536 sectors using a blocksize of 65536 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 copied
1.39247 seconds
optimal blocksize is 65536 sectors (32.00 MiB)
copy 1257570229 sectors using a blocksize of 65536 sectors  05:24:41    ( SUCCESS )
        
1257570229 of 1257570229 copied
1258291125 sectors copied
move partition to the right  00:00:01    ( SUCCESS )
        
old start: 272960478
old end: 1531251602
old size: 1258291125 (600.00 GiB)
new start: 695228940
new end: 1953520064
new size: 1258291125 (600.00 GiB)
update boot sector of ntfs file system on /dev/sda5  00:00:00    ( SUCCESS )
check file system on /dev/sda5 for errors and (if possible) fix them  00:00:01    ( ERROR )
        
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: 860449116672 bytes (860450 MB)
Current device size: 644245056000 bytes (644246 MB)
ERROR: Current NTFS volume size is bigger than the device size!
Corrupt partition table or incorrect device partitioning?
libparted messages    ( INFO )
        
Error informing the kernel about modifications to partition /dev/sda4 -- Device or resource busy. This means Linux won't know about any changes you made to /dev/sda4 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
The kernel was unable to re-read the partition table on /dev/sda (Device or resource busy). This means Linux won't know anything about the modifications you made until you reboot. You should reboot your computer before doing anything with /dev/sda.
Comment 2 Curtis Gedak 2009-11-11 18:00:19 UTC
I think I have discovered an anomaly in the above gparted log file that relates to a problem informing the kernel about modifications to the partition table.


BACKGROUND INFORMATION

When shrinking and moving a partition to the right, GParted will perform the following steps:
1) Check the file system for errors and if possible fix them
2) Shrink the file system
    a) Run simulation shrink file system
    b) Really shrink the file system
    c) Shrink the partition
3) Check the file system for errors and if possible fix them
4) Grow the file system to fill the partition
    a) Run grow file system simulation first
    b) Really grow the file system

Note that if a failure is encountered at any step in this process then the remaining steps are not executed.


THEORY
From the GParted log file it appears than when step 4 executed, the command "ntfsresize" read the partition as being the previous size of 860,450 MB instead of the new partition size of 644,246 MB.  Hence this last step grew the file system to be the size of what ntfsresize thought was the current partition size.


Snippet from above gparted_details.htm:
<...snip>
grow file system to fill the partition  00:00:09    ( SUCCESS )

run simulation  00:00:05    ( SUCCESS )

ntfsresize -P --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: 644245049856 bytes (644246 MB)
Current device size: 860449121280 bytes (860450 MB)
New volume size : 860449116672 bytes (860450 MB)
<snip....>


This reading by ntfsresize of the old partition size is further corroborated by the libparted message that indicates a problem informing the kernel of changes to the partition table on /dev/sda.


THOUGHTS
I am still at a loss as to why this occurred and so far have been unable to reproduce it.  My suspicion is that it is related to the interaction between libparted and newer Linux kernels.

To reduce the likelihood of this particular case occurring, I am considering removing step 4 from the logic as this step should not be necessary.
Comment 3 Curtis Gedak 2009-11-11 22:19:20 UTC
I have successfully confirmed the problem with GParted Live 0.4.8-1.

This Live CD uses:
GParted 0.4.8
Parted 1.9.0
Linux Debian 2.6.30-2-486

I still suspect that the problem is related to the interaction with newer Linux kernels.

Based on this hypothesis, I will investigate older GParted Live versions to try to find one that does not exhibit this problem.
Comment 4 Curtis Gedak 2009-11-11 22:59:44 UTC
GParted Live 0.4.6-1 does not appear to exhibit this problem.

GParted Live 0.4.6-1 uses:
GParted 0.4.6
Parted 1.8.8
Linux Debian 2.6.30-backports.1-486

Until I can isolate the exact cause of this problem, GParted Live 0.4.6-1 is the Live CD I recommend for use when resizing NTFS file systems.
Comment 5 Curtis Gedak 2009-11-11 23:23:41 UTC
To my recollection, the portion of code that performs the resize operation has not been changed for many versions of GParted (at least since Gparted 0.3.4).

I have not experienced the problem using:
GParted 0.4.8
Parted 1.9.0
Linux Hardy 2.6.24-23-generic

Hence I believe that the problem will surface in any version of GParted that uses Parted 1.9.0 and a newer Linux kernel.  More investigation is required to pinpoint the exact cause of the problem.
Comment 6 Curtis Gedak 2009-11-12 16:56:06 UTC

The crux of the problem appears to be that when a change is made to the partition table using GParted (libparted), the kernel is not aware of the change.  This causes problems when other utilities directly read the partition table from the kernel and perform actions based on this view, which is different than the one recently changed by GParted (libparted).

To recreate symptoms of the problem use:
GParted 0.4.8 (the version does not seem to matter)
Parted 1.9.0
Linux 2.6.30 (the problem does not appear with 2.6.24)

1)  Start GParted
2)  Create a partition table on a new disk device
3)  Create an NTFS partition that spans the whole device
4)  Quit GParted
5)  Check that the partition is recognized using "blkid" command
6)  Start GParted
7a)  Resize the NTFS partition to span only half of the device
       (don't click close on progress window)
7b)  Expand the Details view and observe that in the last entry
       that ntfsresize will grow the partition to fill the whole drive!!!
   *** It is at this point that the partition table size (half of drive)
       is a mismatch with the NTFS file system size (whole drive)
7c)  Close the progress window
8)  Close GParted
Comment 7 Curtis Gedak 2009-11-12 17:26:02 UTC
The problem does not appear on Karmic Ubuntu 9.10 when I use the parted version bundled with Ubuntu 9.10:
GParted 0.4.8
Parted 1.8.8.1.159-1e0e
Linux 2.6.31

When I upgrade to Parted 1.9.0 I can confirm the problem exists using Karmic Ubuntu 9.10 with:
GParted 0.4.8
Parted 1.9.0
Linux 2.6.31
Comment 8 Curtis Gedak 2009-11-12 18:03:39 UTC
The more I think about this, the more I think this problem is related to a recent change with Parted 1.9.0, and the interaction with newer Linux kernels.

Back in October I noticed a change in behaviour of Parted 1.9.0 and commented on the code change in the following mailing list thread:

http://lists.alioth.debian.org/pipermail/parted-devel/2009-October/003255.html

The relevant code change appears to be:
http://git.debian.org/?p=parted/parted.git;a=commitdiff;h=1d8f9bece138e4d8e58f7b059b4195aff6f39deb;hp=d16300a88d9200e0f1e08d56e39392e028412611

This post was regarding a problem updating the kernel view of changes to partition tables when at least one partition was mounted.

Perhaps the problem noted in the thread is even more widespread and affects devices with no mounted partitions with newer Linux kernels???

More investigation is required....
Comment 9 Curtis Gedak 2009-11-12 18:15:29 UTC
My apologies for the entries in comment #8.  These related to a change between parted-1.9.0 and parted-2.0, and not to a change introduced in parted-1.9.0.

I think I need some time to step back from the problem to allow my head to clear.  :)
Comment 10 Curtis Gedak 2009-11-14 17:19:45 UTC
So far, the problem only seems to appear with some combinations of GParted, Parted, and newer Linux kernels.

The following scenario _does not_ exhibit the resizing problem:
GParted 0.4.8
Parted 1.9.0
Linux 2.6.24-23 (Kubuntu Hardy Heron 8.04)

The following scenario _does_ exhibit the resizing problem:
GParted 0.4.8
Parted 1.9.0
Linux 2.6.31-14 (Ubuntu Karmic Kameleon 9.10)

The following scenario _does not_ exhibit the resizing problem:
GParted 0.4.8
Parted 1.8.8.1.159-1e01
Linux 2.6.31-14 (Ubuntu Karmic Kameleon 9.10)

This leads me to believe that there is some interaction between Parted and newer Linux kernels that causes the resizing problem.  Using this knowledge I have been trying to reproduce the problem with Parted alone (no GParted).  So far I have been unsuccessful in this endeavour.
Comment 11 Curtis Gedak 2009-11-15 16:32:08 UTC
Created attachment 147790 [details]
Dangerous script to test problem resizing partition

Attached is dangerous script I was working on to demonstrate the file system resizing problem.

This script would require further work prior to submitting to parted if this were to be raised as a parted bug.

Fortunately, Francois Dupoux has found a patch for the problem.  :)
See the following email:
http://sourceforge.net/mailarchive/forum.php?thread_name=580e35610911150325g778142b9jb43b170429971f7d%40mail.gmail.com&forum_name=gparted-devel
Comment 12 Szabó Péter 2009-11-16 12:29:32 UTC
*** Bug 602067 has been marked as a duplicate of this bug. ***
Comment 13 Curtis Gedak 2009-11-16 23:20:38 UTC
The problem reported regarding resizing errors with GParted has been identified as a problem with unpatched versions of parted.  The problem with parted not informing the kernel of changes to the partition table has been fixed with a patch.

Patch for 'commit to os' for linux:
http://git.debian.org/?p=parted/parted.git;a=commit;h=ad25892bb995f61b0ddf801ed1f74e0b1e7390ce

This problem would occur with newer Linux kernels and unpatched parted-1.9.0.

To avoid this problem, do not use GParted with an unpatched parted-1.9.0.

Patched versions of Parted can be found at the fedora site:
http://koji.fedoraproject.org/koji/buildinfo?buildID=129982
Comment 14 Curtis Gedak 2009-11-17 20:03:06 UTC
The GParted forum post used to track instances of this problem is:
http://gparted-forum.surf4.info/viewtopic.php?id=13777

If you experience this problem, please post a request for help in the GParted forum.  Useful information for trouble shooting this problem is the output from the following commands:

     fdisk -l -u
     where:  One of the above options is a lower case "L" and not the number one.

     parted /path-to-your-disk-device unit s print
     where: /path-to-your-disk-device is something like /dev/sda.

Closing this bug with a status of NOTGNOME because the patch required is for the parted-1.9.0 code.
Comment 15 Curtis Gedak 2009-12-05 21:11:31 UTC
Instructions on how to apply the fedora patches to parted-1.9.0 can be found at the following link:
http://gparted-forum.surf4.info/viewtopic.php?id=13827