Partitioning Wizard My Ass . . .

April 22, 2007 9:18 PM

An unlucky series of partition moves, copies and resizes has led to GPartEd saying my NTFS partition is one size, but windows thinking it's another. What the Christ? Seemingly impossible screenshots and

Order of events:

- Installed Feisty using the 'resize NTFS partition and used freed-up space' option. Accidentally made my windows partition 13 GBs (my bad).
- Began attempting to fix this - resized ubuntu root partition to ~10GBs. Screenshot here.
- Got to this state, where I had things as I wanted. If this state was real, I'd be happy.
- Upon booting into windows, I found this.

If I remove 1GB of files from the NTFS partition in windows, the same amount is removed from the GPartED representation of that partition in lunix. I've attempted to resize again in the hopes of it 'shocking' windows into realizing the size of the partition, but no dice. Honestly I don't know which of the two operating systems is telling me the truth.

I would really like to get the NTFS partition utilize the 12+ GBs it's not recognizing. Any ideas?

posted by datacenter refugee to computers & internet (9 comments total)

Partition Doctor.

Also:

R-Studio NTFS

The former is able to work wonders on partitions, the latter, able to recover any data at all so long as it hasn't been completely blasted.

A complete bombing of the partitions and format/re-partition after recovery might be necessary.

Partition altering is something of a dark art. If you mess with the MFTs and boot sectors, very very bad things can happen, but not such that the drive is completely inaccessible by R-Studio.
posted by disillusioned at 1:42 AM on April 23, 2007 [1 favorite has favorites]

To work through this, you need to understand the difference between a partition size and a filesystem size.

A partition is just a bunch of contiguous disk blocks. It starts at block N, and occupies all disk blocks from N to (N + partition_size - 1) inclusive. There's a type code and a few flags in the partition table that serve as a hint about what the partition is going to be used for, but the partition itself doesn't have any more structure than a starting block and a size.

Windows treats partitions as if they were separate disk drives, giving each one a drive letter.

A filesystem (like NTFS or FAT32 or ext3) is a way to organize files within a partition. Filesystems have assorted structures that identify which blocks are available for use and which are used. When a filesystem is initially built on a partition (or in Windows parlance, when the partition is formatted) these structures are set up based on the underlying partition size. When the filesystem is in use, no reference is made to the underlying partition size - free space and used space are all calculated based on what's in the filesystem's own structures.

Windows is a bit vague about these distinctions. When Windows reports the total size of a "disk", it's actually reporting the total number of blocks managed by the filesystem that's built on whatever partition.

So what's happened to you?

In order to shrink your original Windows partition to the 13GB you originally asked for, and do so without causing horrible corruption within the NTFS filesystem already built there, gparted has had to modify that filesystem so that it only manages the first 13GB worth of blocks in the partition; only then did it shrink the actual partition.

When you subsequently expanded the partition back to 25GB, gparted has taken a conservative approach: a 25GB partition is big enough to fit a 13GB filesystem without further fiddling, so it hasn't fiddled, and you've ended up with a 25GB partition that has a 13GB filesystem built on it.

Both OSes are telling you the truth - they're just telling it about different things. If you want confirmation from Windows that gparted doesn't lie, right-click My Computer and select Manage, then click Disk Management; I'm betting you'll see that the partition allocated for C: is indeed 25GB.

If that were my machine, I'd be doing the following:

1. Boot it into Ubuntu.


2. Start a terminal.


3. Use the command
   
sudo ntfsclone --output - --save-image /dev/sda1 | gzip -9 | split -b 640m - /media/sda5/sda1.ntfsclone.gz.

   to make a block-for-block backup of my NTFS partition, so if everything goes horribly wrong, at least I could restore it to its exact present state.


4. Use the command
   
sudo ntfsresize -n /dev/sda1

   to see if ntfsresize reckons it's safe to expand the NTFS filesystem on /dev/sda1 back to the full size of the underlying partition; and if so,


5. Use
   
sudo ntfsresize /dev/sda1

   to do the actual business.


6. Boot into Windows, let it run the disk consistency check that ntfsresize will have scheduled, and see whether C: is now a 25GB filesystem as expected.


7. If so, delete F:\sda1.partimage.gz.* (maybe after burning them all to CD-ROM or DVD-R first - you can't have too many backups).

But if you'd rather spend money on mysterious tools that work by magic, you go right ahead :-)
posted by flabdablet at 4:41 AM on April 23, 2007 [1 favorite has favorites]

Sorry - skipped a step. Before you back your NTFS partition up with ntfsclone, you should use

sudo umount /dev/sda1

to ensure you have unencumbered access to the partition.
posted by flabdablet at 4:46 AM on April 23, 2007

If you want confirmation from Windows that gparted doesn't lie, right-click My Computer and select Manage, then click Disk Management; I'm betting you'll see that the partition allocated for C: is indeed 25GB.

bingo. Thanks for the explanation. I knew something was fishy. I'll connect an external drive tonight and then try the manual ntfs resize. Thanks to both of you!
posted by datacenter refugee at 5:30 AM on April 23, 2007

flabdablet: I wish there was a way we could all mark that as a best answer. ("Favorite" just doesn't seem to cut it, for me.)
posted by insipidia at 1:27 PM on April 23, 2007

You shouldn't actually need an external drive; looks like there's more than enough space left on /media/sda5 (F:) for a compressed image of /dev/sda1 (C:), and neither ntfsclone nor ntfsresize will touch the partition table. I commend your caution, though.
posted by flabdablet at 3:33 PM on April 23, 2007

Also, just looking over what I posted before, it's important to know that

sudo ntfsclone --output - --save-image /dev/sda1 | gzip -9 | split -b 640m - /media/sda5/sda1.ntfsclone.gz.

must be all on one command line; looks like my conversion of ' ' to ' ' was a little sloppy before.

What that command actually does is tells ntfsclone to write out all the used blocks from the NTFS filesystem on partition /dev/sda1, using its special image format (--save-image), to standard output (-); pipe the result into gzip -9 to compress it; then pipe the compressed result into split, which will break its standard input (-) into 640MiB chunks, and write those out as /media/sda5/sda1.ntfsclone.gz.aa, /media/sda5/sda1.ntfsclone.gz.ab, /media/sda5/sda1.ntfsclone.gz.ac...

640MiB is a handy size for burning to CD-ROM or DVD-R (seven fit nicely on a DVD), and is also well under the 2GB FAT32 file size limit, so you'll have no trouble writing the files out.

Should you ever need to restore an NTFS partition from a backup made this way, the command to do that would be

sudo cat /media/sda5/sda1.ntfsclone.gz.* | gunzip | sudo ntfsclone --overwrite /dev/sda1 --restore-image -

posted by flabdablet at 3:57 PM on April 23, 2007

Just to verify for anyone else who stumbles upon this thread that the NTFS resize did indeed fix the issue. I was prepared for an hour-long partition resizing procedure but it actually took <10 seconds. Thanks again.
posted by datacenter refugee at 9:57 PM on April 23, 2007

Yeah, it's generally quicker to enlarge a filesystem than to shrink it, because there's generally no need to move any files around; you just end up with a large chunk of free space at the end.
posted by flabdablet at 3:41 AM on April 24, 2007