Hey all,

I have the following linux partitions:

hda5: XFS 78.83 GB
hda6: XFS 5.86 GB
hda7: swap 1 GB

Up until tonight, hda5 was running SuSE 9.2 and hda6 had Gentoo. I found that I was spending most of my time in Gentoo and didn't really care about SuSE all that much. I filled up hda6 and ran out of space, so I wanted to back it up and put it on hda5.

The back up and restore (using kdar/dar) went amazingly well, since I'm a total newb when it comes to backups. hda5 is booting up and everything. I thought at least the relocation of boot files and stuff in my /etc would have caused some problems. (Actually, I hda forgotten to update my fstab, but that wasn't hard to fix).

The only problem I'm having is that when I run df on my hda5, it still thinks it's 5.83 GB, with only 241 MB left. I know for a fact this is wrong. fdisk, cfdisk and qtparted are all reporting the correct size for the partition. Somehow, a file got included in my backup that is telling the kernel that my partition is still the smaller size.

I even thought maybe if I started fdisk and quickly saved without changing anything, that would update the filesystem with the partition table.

Is there a command that I can give to update the filesystem with the right partition size to pay attention to? I know for a fact I'm on hda5 and not the hda6 I was using.

I'm wondering if I just download 300+ MBs of stuff, I wonder if the filesystem will cut me off because it thinks it's outta room.

Anyway, thanks for any help anyone can give.

Wackman

You can resize the file system to fit the partition while booted in a livecd.

# Run the e2fsck with the force option.
e2fsck -f /dev/hda5

# Then run the resize operation.
resize2fs -f /dev/hda5

Still no luck. No matter what filesystem I use, it refuses to take the whole size of the partition. I have well over 60 GB free, but it tells me with 5 GB installed, I only have about 100 MB free.

The partition was XFS, so I kinda adapted your suggestion for that fs. I tried using xfs_growfs on it, but it did nothing. Didn't touch it. I even tried using the -d option which tells it to fill the entire size of the partition, but it laughed at me.

So I thought it was just XFS being picky. I decided to try using ext2. If I got that to work, it wouldn't be hard to add a journal to it making it ext3 (not a huge fan of that fs, but it's better than nothing). resize2fs also refused to do anything to it.

Finally, I started over. I reformated /dev/hda5 as JFS. No change. It still thinks it's only got about 111MB left. This time, I told kdar to ignore extended attributes, thinking that there was some archive bit or attribute locking the size of the filesystem. That didn't help

This is frustrating me. I'm anxious to get everything working right. Please help.

I guess you happened to backup and restore not only the file system, but patitition table too, which may also contain partition size data.

If so, then I think you could safely resize the partition with e.g. qtparted.

Well, this morning, I used systemrescuecd (forget the url right now) to try to use qtparted. It couldn't/wouldn't budge either hda5 (the new larger partition) or hda6 (the old small partition). All I could do was delete. So I deleted all my extended partitions and created hda2 (XFS, about 80 GB) and hda3 (swap, about 1 GB). When I left for work, I was restoring my dar backup.

I'm pretty much expecting to be in the same boat when I get home, with hda2 only having 111MB left. If that's the case, I may try to check out dar's website and see if there's a user forum there.

Well, I had a glance at the dar website, and realized that dar backups files and directories, and, as such, it should not backup (and restore) any partition size data.

So, I guess the only reason for your problem may be that though you restored the dar backup to /dev/hda5, your system was still booting up from /dev/hda6.
If so, then stiil /dev/hda6 was mounted to /, so the free space reported for / was the one on /dev/hda6. However, the device names should have revealed this fact for you - so I doubt whether this was the case.

If this is the problem, however, then your problem does not concern dar, but you should configure grub to boot up from /dev/hda5.

It's fixed.

I don't know why, but as long as I had the original filesystem still on the computer, the backup to the larger partition still mirrored the state of the other one. as long as the small partition was still there, the large one reported that it only had 111MB left. Also, if I would update a file on one (EX: /etc/fstab) the same file would get updated on the other one. (I would be booted into one partition and have the other one mounted; updating, say, /mnt/hda6/etc/fstab would update /etc/fstab too).

Anyways, deleting and recreating partitions and restoring to that fixed it.