1 Topic by Battousai

  • Battousai
  • New member
  • Offline
  • Registered: 2008-11-15
  • Posts: 2

Topic: NTFS can't grow up?

Hello all (^_^)/
First I want to thank all the developers of GParted!  I've never really reformatted anything and this program makes it easy (^_^)

I have a question.  Not a problem, I just want to know how things work (^_^)

Long story short:
I had a USB external hard drive with:
1) FAT32, 2) Unallocated, 3) NTFS

I wanted to grow the NTFS into the unallocated section.

What surprised me is that (I think) GParted read the entire NTFS portion (almost completely empty) and then copied all 148 GB up behind the FAT32, which took over 7 hours.

1) FAT32, 2) NTFS, 3) Unallocated

Then it grew the NTFS over the unallocated part, which took seconds.


Am I interpreting that right?  Is that what it does?
Why can't it just grow upwards, instead of moving everything and then growing downwards?




------------------------------------------------------
GParted 0.3.5

Libparted 1.7.1

Grow /dev/sdb2 from 148.06 GiB to 207.15 GiB  07:19:49    ( SUCCES )
        
calibrate /dev/sdb2  00:00    ( SUCCES )
        
path: /dev/sdb2
start: 666263745
end: 976768064
size: 310504320 (148.06 GiB)
calculate new size and position of /dev/sdb2  00:00    ( SUCCES )
        
requested start: 542338335
requested end: 976768064
requested size: 434429730 (207.15 GiB)
new start: 542338335
new end: 976768064
new size: 434429730 (207.15 GiB)
check filesystem on /dev/sdb2 for errors and (if possible) fix them  00:01    ( SUCCES )
        
ntfsresize -P -i -f -v /dev/sdb2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 158978211840 bytes (158979 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 2553 MB (1.6%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 3222 MB 0
Multi-Record : 17146 MB 92
$MFTMirr : 79490 MB 1
Sparse : 17185 MB 30
Ordinary : 79495 MB 10
You might resize at 3221327872 bytes or 3222 MB (freeing 155757 MB).
Please make a test run using both the -n and -s options before real resizing!
move partition to the left  00:00    ( SUCCES )
        
old start: 666263745
old end: 976768064
old size: 310504320 (148.06 GiB)
new start: 542338335
new end: 852842654
new size: 310504320 (148.06 GiB)
move filesystem to the left  07:19:26    ( SUCCES )
        
perform readonly test  01:28:58    ( SUCCES )
        
using internal algorithm
read 310504320 sectors
finding optimal blocksize
        
read 32768 sectors using a blocksize of 128 sectors  00:01    ( SUCCES )
        
32768 of 32768 read
1.18078 seconds
read 32768 sectors using a blocksize of 256 sectors  00:02    ( SUCCES )
        
32768 of 32768 read
1.69911 seconds
optimal blocksize is 128 sectors (64.00 KiB)
read 310438784 sectors using a blocksize of 128 sectors  01:28:50    ( SUCCES )
        
310438784 of 310438784 read
310504320 sectors read
perform real move  05:50:28    ( SUCCES )
        
using internal algorithm
copy 310504320 sectors
finding optimal blocksize
        
copy 32768 sectors using a blocksize of 64 sectors  00:02    ( SUCCES )
        
32768 of 32768 copied
2.025 seconds
copy 32768 sectors using a blocksize of 128 sectors  00:02    ( SUCCES )
        
32768 of 32768 copied
1.68552 seconds
copy 32768 sectors using a blocksize of 256 sectors  00:02    ( SUCCES )
        
32768 of 32768 copied
1.65417 seconds
copy 32768 sectors using a blocksize of 512 sectors  00:02    ( SUCCES )
        
32768 of 32768 copied
2.09522 seconds
optimal blocksize is 256 sectors (128.00 KiB)
copy 310373248 sectors using a blocksize of 256 sectors  05:50:20    ( SUCCES )
        
310373248 of 310373248 copied
310504320 sectors copied
updating bootsector of ntfs filesystem on /dev/sdb2  00:05    ( SUCCES )
        
echo 1f6d5320 | /usr/bin/xxd -r -p | /bin/dd conv=notrunc of=/dev/sdb2 bs=1 seek=28
        
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.0202152 s, 0.2 kB/s
check filesystem on /dev/sdb2 for errors and (if possible) fix them  00:01    ( SUCCES )
        
ntfsresize -P -i -f -v /dev/sdb2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 158978211840 bytes (158979 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 2553 MB (1.6%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 3222 MB 0
Multi-Record : 17146 MB 92
$MFTMirr : 79490 MB 1
Sparse : 17185 MB 30
Ordinary : 79495 MB 10
You might resize at 3221327872 bytes or 3222 MB (freeing 155757 MB).
Please make a test run using both the -n and -s options before real resizing!
grow filesystem to fill the partition  00:00    ( SUCCES )
        
run simulation  00:00    ( SUCCES )
        
ntfsresize -P --force --force /dev/sdb2 --no-action
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 158978211840 bytes (158979 MB)
New volume size : 158978208256 bytes (158979 MB)
Nothing to do: NTFS volume size is already OK.
real resize  00:00    ( SUCCES )
        
ntfsresize -P --force --force /dev/sdb2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 158978211840 bytes (158979 MB)
New volume size : 158978208256 bytes (158979 MB)
Nothing to do: NTFS volume size is already OK.
calculate new size and position of /dev/sdb2  00:00    ( SUCCES )
        
requested start: 542338335
requested end: 976768064
requested size: 434429730 (207.15 GiB)
new start: 542338335
new end: 976768064
new size: 434429730 (207.15 GiB)
check filesystem on /dev/sdb2 for errors and (if possible) fix them  00:01    ( SUCCES )
        
ntfsresize -P -i -f -v /dev/sdb2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 158978211840 bytes (158979 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 2553 MB (1.6%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 3222 MB 0
Multi-Record : 17146 MB 92
$MFTMirr : 79490 MB 1
Sparse : 17185 MB 30
Ordinary : 79495 MB 10
You might resize at 3221327872 bytes or 3222 MB (freeing 155757 MB).
Please make a test run using both the -n and -s options before real resizing!
grow partition from 148.06 GiB to 207.15 GiB  00:01    ( SUCCES )
        
old start: 542338335
old end: 852842654
old size: 310504320 (148.06 GiB)
new start: 542338335
new end: 976768064
new size: 434429730 (207.15 GiB)
check filesystem on /dev/sdb2 for errors and (if possible) fix them  00:00    ( SUCCES )
        
ntfsresize -P -i -f -v /dev/sdb2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 222428021760 bytes (222429 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 2553 MB (1.6%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 3222 MB 0
Multi-Record : 17146 MB 92
$MFTMirr : 79490 MB 1
Sparse : 17185 MB 30
Ordinary : 79495 MB 10
You might resize at 3221327872 bytes or 3222 MB (freeing 155757 MB).
Please make a test run using both the -n and -s options before real resizing!
grow filesystem to fill the partition  00:14    ( SUCCES )
        
run simulation  00:04    ( SUCCES )
        
ntfsresize -P --force --force /dev/sdb2 --no-action
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 222428021760 bytes (222429 MB)
New volume size : 222428017152 bytes (222429 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 2553 MB (1.6%)
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:10    ( SUCCES )
        
ntfsresize -P --force --force /dev/sdb2
        
ntfsresize v2.0.0 (libntfs 10:0:0)
Device name : /dev/sdb2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 158978208256 bytes (158979 MB)
Current device size: 222428021760 bytes (222429 MB)
New volume size : 222428017152 bytes (222429 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 2553 MB (1.6%)
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 ...
Syncing device ...
Successfully resized NTFS on device '/dev/sdb2'.

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

2 Reply by stormhead

  • stormhead
  • Member
  • Offline
  • From: near Frankfurt/Main, Germany
  • Registered: 2008-07-31
  • Posts: 264

Re: NTFS can't grow up?

Hi!

Battousai wrote:

Am I interpreting that right?  Is that what it does?

From my own observations (although they might be wrong ;-) ): Yes, that's what it does.

Why can't it just grow upwards, instead of moving everything and then growing downwards?

Short and simple answer: Because nobody has written an algorithm for this yet. ;-)
Long and more technical answer: On each file system, the file system driver expects a large set of data structures used to manage tha space on the partition at a specified point within the partition. These data structures are often located at the beginning of the partition. As a result, when growing a partition "downwards", these structures have to be moved at the beginning of the partition.
Since these structures store information about which sector is free or used, which sectors have to be read in which order to obtain a given file and so on, and since sector numbering also starts at the beginning of the partition, these structures would have to be completely re-written - which is a quite dangerous process without any proper file system documentation. To my best knowledge, you can obtain the dechnical docs for the NTFS file system from Microsoft - but under license terms that are inacceptable for open source development. Thus, in the Linux world, these docs can not be used for writing NTFS-related tools, and as a result, the developers of the Linux NTFS driver and tools have to conclude how the file system works from observing what's happening on-disk when doing a give task (e.g. writing a file) - a process called "Reverse Engineering". Since you never know if you have interpreted everything absolutely right - and you never know if you've found all the features the file system offers - a set of technical docs obtained this way is very likely to be incomplete or incorrect somewhere - so you better be careful when using them. As a result, you better change as little as possible on a file system while re-organizing the data on it - which effectively means to keep as much as possible of the management structures untouched.
And even if you have the specs for a given file system (which is the case for the typicel Linux file systems), you'd probably better use the same approach, since no piece of software is ever 100% error free - no matter if it is open source or a commercial program, and no matter how much effort, time and money you put into the code (after all, it's all done by humans...).
Don't get me wrong, NTFS support on Linux has come a long way, and it has grown from a ugly and unstable hack to a solution that works perfectly well and reliable on an everyday basis - but sometimes it is still better to trade performance in for security.

3 Reply by Battousai

  • Battousai
  • New member
  • Offline
  • Registered: 2008-11-15
  • Posts: 2

Re: NTFS can't grow up?

Thank you stormhead (^_^)/