1

Topic: The file system is bigger than its volume

I originally thought this might be related to the recent parted bug discussed in the sticky, but I am using the latest version of the LiveCD (0.4.8) downloaded today (23 Nov). I am trying to resize (make smaller) a large FAT32 partition on an external USB drive to create a new ext3 partition on the end. Here's the output of 'fsck -l -u' for this drive:

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              63  2930272064  1465136001    c  W95 FAT32 (LBA)

Here is the info from the details file after I tried to do the shrink and create new partition:

    -------------------

GParted 0.4.8

Libparted 1.9.0
Shrink /dev/sdc1 from 1.36 TiB to 1.17 TiB  00:15:44    ( ERROR )
        
calibrate /dev/sdc1  00:00:00    ( SUCCESS )
        
path: /dev/sdc1
start: 63
end: 2930272064
size: 2930272002 (1.36 TiB)
check file system on /dev/sdc1 for errors and (if possible) fix them  00:02:39    ( SUCCESS )
        
dosfsck -a -w -v /dev/sdc1
        
dosfsck 3.0.6 (04 Oct 2009)
dosfsck 3.0.6, 04 Oct 2009, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
16384 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
366105600 bytes per FAT (= 715050 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 732227584 (sector 1430132)
91526308 data clusters (1499567030272 bytes)
63 sectors/track, 255 heads
0 hidden sectors
2930272002 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdc1: 196934 files, 5976720/91526308 clusters
shrink file system  00:10:23    ( ERROR )
        
using libparted
check file system on /dev/sdc1 for errors and (if possible) fix them  00:02:42    ( SUCCESS )
        
dosfsck -a -w -v /dev/sdc1
        
dosfsck 3.0.6 (04 Oct 2009)
dosfsck 3.0.6, 04 Oct 2009, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
16384 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
366105600 bytes per FAT (= 715050 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 732227584 (sector 1430132)
91526308 data clusters (1499567030272 bytes)
63 sectors/track, 255 heads
0 hidden sectors
2930272002 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdc1: 196934 files, 5976720/91526308 clusters
grow file system to fill the partition  00:00:00    ( ERROR )
        
using libparted
libparted messages    ( INFO )
        
The file system is bigger than its volume!

    --------------

Does anyone have any idea what is going on? It's not real clear to me, even when looking at the details file.

2

Re: The file system is bigger than its volume

Wow!  That is a huge FAT file system!

It would appear that libparted is unable to shrink the volume and is instead complaining that "the file system is bigger than its volume".

You could try the operation using parted directly from the command line.  Perhaps that would provide more details as to the problem.

The format of the command for the resize within parted would be something like:
parted /path-to-disk-device resize partition_number new_start new_end

In you case it might look like:

parted /dev/sdc resize 1 63s 1198GB

3

Re: The file system is bigger than its volume

gedakc wrote:

Wow!  That is a huge FAT file system!

It would appear that libparted is unable to shrink the volume and is instead complaining that "the file system is bigger than its volume".

You could try the operation using parted directly from the command line.  Perhaps that would provide more details as to the problem.

The format of the command for the resize within parted would be something like:
parted /path-to-disk-device resize partition_number new_start new_end

In you case it might look like:

parted /dev/sdc resize 1 63s 1198GB

Thanks! I will try parted from the command line and see what happens. Yeah, that is a monster FAT32 fs. It is hanging off a Linux box, but the OS is old enough I don't completely trust the ntfs code for writing and management wanted to be able to hook it up to a Windows box to extract the data if they had to. That left FAT32 as the only option.

4

Re: The file system is bigger than its volume

Hi, I tried the parted command from the command line as you suggested. It ran to completion and did not print any kind of error messages. However, when I rechecked the disk, both with fdisk and 'parted -l' it still shows the original size:

# parted /dev/sdc resize 1 63s 1198GB

# fdisk -l -u /dev/sdc
Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x8d399bc0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              63  2930272064  1465136001    c  W95 FAT32 (LBA)

# parted -l
Model: WD My Book (scsi)
Disk /dev/sdc: 1500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
1      32.3kB  1500GB  1500GB  primary  fat32        lba

Any other ideas, short of wiping the disk and starting over?

5

Re: The file system is bigger than its volume

Since you are able to demonstrate the problem using only parted, you could try posting the problem in one of the parted mailing lists.
http://www.gnu.org/software/parted/lists.shtml

Unfortunately I am not aware of any other free open source software for resizing FAT file systems that do not use libparted.