GNOME Bugzilla – Bug 601574
ERROR: Current NTFS volume size is bigger than the device size!
Last modified: 2009-12-05 21:11:31 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.
Links to additional forum reports of similar problems follow: http://gparted-forum.surf4.info/viewtopic.php?id=13633 http://gparted-forum.surf4.info/viewtopic.php?pid=21716 http://gparted-forum.surf4.info/viewtopic.php?id=13765 http://gparted-forum.surf4.info/viewtopic.php?id=13757 http://gparted-forum.surf4.info/viewtopic.php?id=13766 http://gparted-forum.surf4.info/viewtopic.php?id=13768
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.
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.
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.
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.
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
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
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....
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. :)
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.
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
*** Bug 602067 has been marked as a duplicate of this bug. ***
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
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.
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