1 Topic by kmikot (edited by kmikot 2009-09-04 06:06:10)

  • kmikot
  • New member
  • Offline
  • Registered: 2009-08-18
  • Posts: 6

Topic: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Please Help!
On NTFS (running WindowsXP) I am trying to increase primary partition. To that end, I need to shrink my 2nd partition. In doing so I get the following error.

check file system on /dev/sda2 for errors and (if possible) fix them  00:00:00    ( ERROR )
        
ntfsresize -P -i -f -v /dev/sda2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 239569498624 bytes (239570 MB)
Current device size: 212722191360 bytes (212723 MB)
ERROR: Current NTFS volume size is bigger than the device size!
Corrupt partition table or incorrect device partitioning?


This is what I had Originally:
sda1 ~=9.7GB (Primary Partition NTFS running Windows XP)
sda2 ~=223 GB (NTFS for Data 60% free )

This is my Goal:
sda1 ~=25GB (Primary Partition NTFS running Windows XP)
unallocated ~10GB
sda2 ~= 198GB (NTFS for Data)

Device Info:
Model: ATAST3250310AS
Size: 232.88 GB
Path: /dev/sda
DiskLabelType: msdos
Heads: 255
Sectors/Track: 63
Cylinders: 30401
Total Sectors: 488 392 065


Full Log File:

GParted 0.4.4

Libparted 1.8.8
Move /dev/sda2 to the right and shrink it from 223.12 GiB to 198.11 GiB  02:17:09    ( ERROR )
        
calibrate /dev/sda2  00:00:00    ( SUCCESS )
        
path: /dev/sda2
start: 20482875
end: 488392064
size: 467909190 (223.12 GiB)
calculate new size and position of /dev/sda2  00:00:00    ( SUCCESS )
        
requested start: 72919035
requested end: 488392064
requested size: 415473030 (198.11 GiB)
new start: 72919035
new end: 488392064
new size: 415473030 (198.11 GiB)
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:01    ( SUCCESS )
        
ntfsresize -P -i -f -v /dev/sda2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 239569502720 bytes (239570 MB)
Current device size: 239569505280 bytes (239570 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 97937 MB (40.9%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 62231 MB 0
Multi-Record : 96651 MB 23869
$MFTMirr : 119785 MB 1
Ordinary : 151583 MB 46613
You might resize at 97936248832 bytes or 97937 MB (freeing 141633 MB).
Please make a test run using both the -n and -s options before real resizing!
shrink file system  00:00:05    ( SUCCESS )
        
run simulation  00:00:03    ( SUCCESS )
        
ntfsresize -P --force /dev/sda2 -s 212722191359 --no-action
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 239569502720 bytes (239570 MB)
Current device size: 239569505280 bytes (239570 MB)
New volume size : 212722184704 bytes (212723 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 97937 MB (40.9%)
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:02    ( SUCCESS )
        
ntfsresize -P --force /dev/sda2 -s 212722191359
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 239569502720 bytes (239570 MB)
Current device size: 239569505280 bytes (239570 MB)
New volume size : 212722184704 bytes (212723 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 97937 MB (40.9%)
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/sda2'.
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 223.12 GiB to 198.11 GiB  00:00:01    ( SUCCESS )
        
old start: 20482875
old end: 488392064
old size: 467909190 (223.12 GiB)
new start: 20482875
new end: 435955904
new size: 415473030 (198.11 GiB)
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:01    ( SUCCESS )
        
ntfsresize -P -i -f -v /dev/sda2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 212722184704 bytes (212723 MB)
Current device size: 239569505280 bytes (239570 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 97936 MB (46.0%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 62231 MB 0
Multi-Record : 96651 MB 23869
$MFTMirr : 119785 MB 1
Ordinary : 151583 MB 46613
You might resize at 97935429632 bytes or 97936 MB (freeing 114787 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:04    ( SUCCESS )
        
run simulation  00:00:02    ( SUCCESS )
        
ntfsresize -P --force /dev/sda2 --no-action
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 212722184704 bytes (212723 MB)
Current device size: 239569505280 bytes (239570 MB)
New volume size : 239569498624 bytes (239570 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 97936 MB (46.0%)
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:02    ( SUCCESS )
        
ntfsresize -P --force /dev/sda2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 212722184704 bytes (212723 MB)
Current device size: 239569505280 bytes (239570 MB)
New volume size : 239569498624 bytes (239570 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 97936 MB (46.0%)
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/sda2'.
calculate new size and position of /dev/sda2  00:00:00    ( SUCCESS )
        
requested start: 72919035
requested end: 488392064
requested size: 415473030 (198.11 GiB)
new start: 72919035
new end: 488392064
new size: 415473030 (198.11 GiB)
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:01    ( SUCCESS )
        
ntfsresize -P -i -f -v /dev/sda2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 239569498624 bytes (239570 MB)
Current device size: 239569505280 bytes (239570 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 97937 MB (40.9%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 62231 MB 0
Multi-Record : 96651 MB 23869
$MFTMirr : 119785 MB 1
Ordinary : 151583 MB 46613
You might resize at 97936248832 bytes or 97937 MB (freeing 141633 MB).
Please make a test run using both the -n and -s options before real resizing!
move file system to the right  02:16:56    ( SUCCESS )
        
perform read-only test  00:44:22    ( SUCCESS )
        
using internal algorithm
read 415473030 sectors
finding optimal blocksize
        
read 65536 sectors using a blocksize of 128 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 read
1.61078 seconds
read 65536 sectors using a blocksize of 256 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
1.57342 seconds
read 65536 sectors using a blocksize of 512 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 read
1.66642 seconds
read 65536 sectors using a blocksize of 1024 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 read
1.67636 seconds
read 65536 sectors using a blocksize of 2048 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
1.29327 seconds
read 65536 sectors using a blocksize of 4096 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
1.05056 seconds
read 65536 sectors using a blocksize of 8192 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
0.808968 seconds
read 65536 sectors using a blocksize of 16384 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
0.713236 seconds
read 65536 sectors using a blocksize of 32768 sectors  00:00:00    ( SUCCESS )
        
65536 of 65536 read
0.748487 seconds
read 65536 sectors using a blocksize of 65536 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 read
0.54081 seconds
optimal blocksize is 65536 sectors (32.00 MiB)
read 414817670 sectors using a blocksize of 65536 sectors  00:44:10    ( SUCCESS )
        
414817670 of 414817670 read
415473030 sectors read
perform real move  01:32:34    ( SUCCESS )
        
using internal algorithm
copy 415473030 sectors
finding optimal blocksize
        
copy 65536 sectors using a blocksize of 64 sectors  00:00:03    ( SUCCESS )
        
65536 of 65536 copied
2.68579 seconds
copy 65536 sectors using a blocksize of 128 sectors  00:00:03    ( SUCCESS )
        
65536 of 65536 copied
2.6676 seconds
copy 65536 sectors using a blocksize of 256 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
2.73949 seconds
copy 65536 sectors using a blocksize of 512 sectors  00:00:03    ( SUCCESS )
        
65536 of 65536 copied
2.48946 seconds
copy 65536 sectors using a blocksize of 1024 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
2.39888 seconds
copy 65536 sectors using a blocksize of 2048 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
2.19603 seconds
copy 65536 sectors using a blocksize of 4096 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
1.95316 seconds
copy 65536 sectors using a blocksize of 8192 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
1.82558 seconds
copy 65536 sectors using a blocksize of 16384 sectors  00:00:02    ( SUCCESS )
        
65536 of 65536 copied
1.57885 seconds
copy 65536 sectors using a blocksize of 32768 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 copied
1.36901 seconds
copy 65536 sectors using a blocksize of 65536 sectors  00:00:01    ( SUCCESS )
        
65536 of 65536 copied
1.32658 seconds
optimal blocksize is 65536 sectors (32.00 MiB)
copy 414752134 sectors using a blocksize of 65536 sectors  01:32:11    ( SUCCESS )
        
414752134 of 414752134 copied
415473030 sectors copied
move partition to the right  00:00:00    ( SUCCESS )
        
old start: 20482875
old end: 435955904
old size: 415473030 (198.11 GiB)
new start: 72919035
new end: 488392064
new size: 415473030 (198.11 GiB)
updating boot sector of ntfs file system on /dev/sda2  00:00:00    ( SUCCESS )
        
echo fba75804 | /usr/bin/xxd -r -p | /bin/dd conv=notrunc of=/dev/sda2 bs=1 seek=28
        
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.0160068 s, 0.2 kB/s
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:00    ( ERROR )
        
ntfsresize -P -i -f -v /dev/sda2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 239569498624 bytes (239570 MB)
Current device size: 212722191360 bytes (212723 MB)
ERROR: Current NTFS volume size is bigger than the device size!
Corrupt partition table or incorrect device partitioning?

========================================
Grow /dev/sda1 from 9.77 GiB to 25.00 GiB

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

2 Reply by kmikot

  • kmikot
  • New member
  • Offline
  • Registered: 2009-08-18
  • Posts: 6

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Anyone ?! Can anyone out there lend a hand?

Looking at the log file it looks like my "device size" changed. Does that refer to the physical disk? How can that change? Throughout the log it reports it as 239569505280 bytes. Then the entry that reports the error reports "device size" as 212722191360 bytes.

Can anyone please explain?

3 Reply by cmdr

  • cmdr
  • Member
  • Offline
  • Registered: 2008-07-30
  • Posts: 522

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Hello kmikot,
volume size : the logical size of the (NTFS) filesystem, given by values stored in the PBR (Partition Boot Record)
device size : the physical size of the partition containing a filesystem (or volume) as indicated by the MBR (Master Boot Record).

You have got a missmatch between these two values. Obviously the filesystem was not adapted to the new smaller device size.

I think, I know, why this happened.

echo fba75804 | /usr/bin/xxd -r -p | /bin/dd conv=notrunc of=/dev/sda2 bs=1 seek=28
       
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.0160068 s, 0.2 kB/s
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:00    ( ERROR )

The lower border of sda2 was moved upwards to get space for the first primary partition sda1, but the value for the new lower border is not correctly updated in PBR ( but in MBR, of course).
Byte 29 to 32 in the PBR is set with the above code sequence and contains the so called "Hidden sector value", which is de facto the absolute location of the PBR in sectors. Probably this value points still to the former location. It's possible to edit and correct it, but to verify it, needs a little bit of effort by you. It's not quite clear, whether you grew sda1 successfully with the same procedure. If not, you could also move sda2 back to exactly its former size and lower border (in sectors, see above log file), check it and run "chfdsk /f /r" from Windows ... and restart resizing. Do NOT grow sda1 with the same task. Do it in a second step, after the first was successful.

Regards
cmdr

4 Reply by kmikot

  • kmikot
  • New member
  • Offline
  • Registered: 2009-08-18
  • Posts: 6

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

First of all, thank you so much for responding cmdr! I appreciate the time.

At a high level I understand and agree. But, I do need some clarification and detail. See below (in red)...

cmdr wrote:

Hello kmikot,
volume size : the logical size of the (NTFS) filesystem, given by values stored in the PBR (Partition Boot Record)
device size : the physical size of the partition containing a filesystem (or volume) as indicated by the MBR (Master Boot Record).

You have got a missmatch between these two values. Obviously the filesystem was not adapted to the new smaller device size.

I think, I know, why this happened.

echo fba75804 | /usr/bin/xxd -r -p | /bin/dd conv=notrunc of=/dev/sda2 bs=1 seek=28
       
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.0160068 s, 0.2 kB/s
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:00    ( ERROR )

The lower border of sda2 was moved upwards to get space for the first primary partition sda1, but the value for the new lower border is not correctly updated in PBR ( but in MBR, of course).
Byte 29 to 32 in the PBR is set with the above code sequence and contains the so called "Hidden sector value", which is de facto the absolute location of the PBR in sectors. Probably this value points still to the former location. It's possible to edit and correct it, but to verify it, needs a little bit of effort by you.  (Can you point me in the right direction to do this?) It's not quite clear, whether you grew sda1 successfully with the same procedure. (How can I determine this? Is this what the log refers to: "Successfully resized NTFS on device '/dev/sda2'."?) If not, you could also move sda2 back to exactly its former size and lower border (in sectors, see above log file),  (Is it possible/safe to just change the lower limit back, since my understanding is that the data on sda2 has already been moved up)check it  (How?)and run "chfdsk /f /r" from Windows ... and restart resizing. Do NOT grow sda1 with the same task. Do it in a second step, after the first was successful. (Agree!)

Regards
cmdr

THANKS AGAIN!
kmikot

5 Reply by cmdr

  • cmdr
  • Member
  • Offline
  • Registered: 2008-07-30
  • Posts: 522

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Hello kmikot,

BTW, you used the latest stable release of "GParted Live", didn't you ?

cmdr wrote:

It's not quite clear, whether you grew sda1 successfully with the same procedure.

sda1 = C: . Does volume C: now have a size of 25 GiB as intended ( therefore "occupying" the former sda2 start sectors)?

kmikot wrote:

(How can I determine this? Is this what the log refers to: "Successfully resized NTFS on device '/dev/sda2'."?)

1st question : size of sda1 / C: , shown by "GParted" or Windows
2nd question : No, sda2 = D: (?)

kmikot wrote:

(Is it possible/safe to just change the lower limit back, since my understanding is that the data on sda2 has already been moved up)

No, since the filesystem was successfully moved upwards due to the log file. You may easily move it down again with "GParted" to its exact former position (and size), provided that sda1 (=C:) was not yet grown to its new (25 GiB) size (see above).

It's possible to edit and correct it, but to verify it, needs a little bit of effort by you.  (Can you point me in the right direction to do this?)

What do we need ?
1. "GParted Live CD", latest stable release; no "embedded" versions in other Linux distros
2. An USB Stick (>= 128 MB) or an external harddisk to store files permanently and transfering them to a file sharing site.

How to proceed ?

1. Attach your USB stick and then boot "GParted" CD (CDROM must be first device in BIOS Boot Sequence)

2. After "GParted" stops scanning, note your USB stick's device name. I use as example "sdb1". Be sure to replace it with your device's name, whenever it appears in the following code. Close "GParted" window and open "Terminal" window (icon on top of the desktop)

3. Mounting the USB stick (type at the prompt and confirm each line with [ Enter ]:

mkdir /mnt/usb
mount /dev/sdb1 /mnt/usb
mkdir /mnt/usb/gparted

4. Writing MBR of sda to USB stick :

dd  if=/dev/sda  of=/mnt/usb/gparted/sda.mbr  bs=512  count=1

5. Shutdown "GParted" and upload file "sda.mbr" (in subfolder "gparted" of your stick) to a file sharing site, e.g. mediafire.com and give us the link.

This is the first step, so that I can give you the code to get PBR of sda2. You should keep in mind, how to mount your stick (see item 3; without creating subfolder "gparted" again, of course). I won't mention it anymore.

Regards
cmdr

6 Reply by kmikot

  • kmikot
  • New member
  • Offline
  • Registered: 2009-08-18
  • Posts: 6

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Again, thanks for your time. This situation has not gone away. I have simply been away (out of town)

Answers to questions, etc:

cmdr wrote:
    BTW, you used the latest stable release of "GParted Live", didn't you ?
At the time I started this project I got the latest stable version of gParted. It was 0.4.4

cmdr wrote:
    It's not quite clear, whether you grew sda1 successfully with the same procedure.
I got confused in my inital response. sda1 did not grow. It did not change. It is the original size.

cmdr wrote:
    What do we need ?
I uploaded the file to:
http://www.keepandshare.com/doc/view.ph … 4&da=y

kmikot

7 Reply by cmdr

  • cmdr
  • Member
  • Offline
  • Registered: 2008-07-30
  • Posts: 522

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Hello kmikot,

"sda.mbr" looks pretty good and corresponds to what is documented in the detailed log-file of your first post.

I need to have two more files ("sda2_old.pbr" and "sda2_new.pbr") :

dd  if=/dev/sda  of=/mnt/usb/gparted/sda2_old.pbr  bs=512  skip=20482875  count=100

dd  if=/dev/sda of=/mnt/usb/gparted/sda2_new.pbr  bs=512  skip=72919035  count=100

Regards
cmdr

8 Reply by kmikot

  • kmikot
  • New member
  • Offline
  • Registered: 2009-08-18
  • Posts: 6

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Thanks.  More files...

dd  if=/dev/sda  of=/mnt/usb/gparted/sda2_old.pbr  bs=512  skip=20482875  count=100
http://www.keepandshare.com/doc/view.ph … 5&da=y

dd  if=/dev/sda of=/mnt/usb/gparted/sda2_new.pbr  bs=512  skip=72919035  count=100
http://www.keepandshare.com/doc/view.ph … 4&da=y

kmikot

9 Reply by cmdr

  • cmdr
  • Member
  • Offline
  • Registered: 2008-07-30
  • Posts: 522

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Hello kmikot,

cmdr wrote:

The lower border of sda2 was moved upwards to get space for the first primary partition sda1, but the value for the new lower border is not correctly updated in PBR ( but in MBR, of course).

I was wrong; it's just the other way round.  The new lower border of sda2 is correct, but the former size value is still used, thus exceeding the physical size of the harddisk.

I corrected the false value with the appropriate value from MBR ... and now let's see, what happens !

Download sda2_corr.pbr

Load my new PBR to your harddisk.
(BEWARE OF TYPOS !)

dd  if=/mnt/usb/gparted/sda2_corr.pbr  of=/dev/sda2  bs=512   count=1

Then let "GParted" CHECK the partition again. Afterwards use Windows "chkdsk /f /r" multiple times, until there are no more faults.

If you want to grow sda1 (C:) finally,  be sure to uncheck cylinder border alignment to avoid running into the next problem !

Regards
cmdr

10 Reply by kmikot

  • kmikot
  • New member
  • Offline
  • Registered: 2009-08-18
  • Posts: 6

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Thanks cmdr!!!!

That did the trick!
I am curious. Do you think this problem was from something I did wrong?
Was the cause resolved in the later releases?

Thanks
koter

11 Reply by cmdr

  • cmdr
  • Member
  • Offline
  • Registered: 2008-07-30
  • Posts: 522

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

Hello kmikot,
congratulations !!!

I am curious. Do you think this problem was from something I did wrong?

No, not really. Resizing AND moving  NTFS partitions are very complex tasks. There are much things, which might go wrong. It's reported, that resizing in several smaller steps might be safer than doing it in one big step. But I think, that 25 GiB isn't too big a chunk.

Was the cause resolved in the later releases?

Since M$ doesn't publish the specifications of NTFS, the libparted programmers have to reverse-engineer M$ code for their programming purposes. So it's inevitable, that they often are one step behind. As a conclusion, you should always use the latest stable release of "GParted Live", if NTFS partitions are involved, because you are as close as possible to the actual NTFS specifications.

Regards
cmdr

12 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

cmdr,

I've had some time recently to look into this problem and I think I have discovered an anomaly in this thread.

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 shrink file system simulation first, and if successful then
    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, and if successful then
    b) Really grow the file system

Theory
In this thread, it appears than when step 4 executed, the command "ntfsresize" read the partition as being the previous size of 239570 MB instead of the new partition size of 212723 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:
<...stuff deleted>
grow file system to fill the partition  00:00:04    ( SUCCESS )
       
run simulation  00:00:02    ( SUCCESS )
       
ntfsresize -P --force /dev/sda2 --no-action
       
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 212722184704 bytes (212723 MB)
Current device size: 239569505280 bytes (239570 MB)
New volume size : 239569498624 bytes (239570 MB)
<stuff deleted....>

Thoughts
I am still at a loss as to why this occurred and so far have been unable to reproduce it.

To reduce the likelihood of this particular case occurring, I could essentially remove step 4 from the logic.  I think that the original author added the grow functionality to the "Partition -> Check" menu option because sometimes the partition would grow, but the file system would fail to grow.  Adding this second "grow" made an easy way for users to expand the file system without having to try resizing back to the original size, and then resizing larger.  At least that is why I think this functionality was added to the "check" operation.

The problem has me concerned because several users have experienced this problem recently.  If you have any thoughts as to why this occurs I would certainly appreciate hearing your ideas.

13 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: SOLVED-ERROR: Current NTFS volume size is bigger than the device size!

NOTE:  We are tracking a problem with GParted resizing file systems.  See post:
WARNING! Problem Resizing File Systems with GParted

For new users experiencing this problem, please open a new post and do not add to this thread.