DIsk is full? du says not

opensuse v11.3
linux x86_64

As reported by df below the </home> volume is full. However, du claims only 2.4GB are used.

Where do I go from here?

root:/> du -sh /home
du: cannot access `/home/sma-user8/.gvfs': Permission denied
2.4G	/home

&gt; df -h
Filesystem            Size  Used Avail Use% Mounted on
                       20G  6.9G   12G  37% /
devtmpfs              1.8G  348K  1.8G   1% /dev
tmpfs                 1.9G  848K  1.9G   1% /dev/shm
/dev/sda1              69M   28M   37M  44% /boot
                       25G   24G     0 100% /home
/dev/sdc1             231G   12G  207G   6% /misc
/dev/sdb1             230G   19G  199G   9% /data01

On my computer, the df -h command shows:

/dev/sda3 60G   25G   32G  44% /home

Showing the location as Partition /dev/sda3 as I use a seperate /home partition. Your shows:

/dev/mapper/system-home 25G   24G     0 100% /home

I do not understand this result. Why not give us the output from an fdisk -l command as in:

su -
fdisk -l

And then how about a copy of your fstab file as well:

cat /etc/fstab

Just copy and past the results into a code block (#) while in the advanced message editor and perhaps we will see the problem you are having.

Thank You,

That large a difference, 25G, vs 2.4G, typically indicates that there is a file (or several files) that are in use by a program, even though the file has been deleted. The file does not show in a directory, so “du” won’t find it. However, “df” is listing the actual used space and is not looking at directories, so it will find the space that is being used.

The good news, is that this should correct itself on reboot.

“fsck -n /dev/mapper/system-home” might list the inode number and owner of the file(s).

The chances are that you know what happened. There was probably a program running that was creating a large file, and you deleted that file but failed to kill the program that was creating it.

Yes, it did.

The chances are that you know what happened.

I am fairly certain which program it was: VirtualBox.

Until several weeks ago I had crontab set up to backup the VMs once a week; backup requires shutting down the VM. I went out of town for several days and disabled the backup run, then forget to enable it on return. The VM had been running continuously since then.

That sounds likely.

So we have a problem both solved and explained. That seems to be a good outcome.