I just did something similar to this:
$ du -sh /bigdata/stuff
1022G /bigdata/stuff
$ df -h /bigdata
Fileystem Size Used Avail Used% mounted on
/dev/sda5 1,8T 1,7T 140G 93% /bigdata
$ rm -rf /bigdata/stuff/*
$ df -h /bigdata
Fileystem Size Used Avail Used% mounted on
/dev/sda5 1,8T 1,6T 268G 86% /bigdata
which means that deleting 1022 G of files only gave me 128 G of additional free space.
There are no further filesystems mounted under /bigdata and there were no open files on /bigdata at this moment.
In order to reclaim all of the free space, I needed to umount /bigdata (taking v...e...r...y long) and mount it again. After that, everything was back to normal.
According to fsck, there are no filesystem errors (fsck was performed only for error checking, it is not needed for reclaiming the space).
According to a S.M.A.R.T. extended self test, the harddisk does not have hardware errors.
Does anybody know what's wrong ?
System info:
I am using ext4 on Ubuntu Server 12.04 64bit on a harddisk bought a few months ago, so there are no inherited problems from a previous installation (as there is none). The filesystem was created using -m 0 (0% reserved for root).
History:
I already noticed this problem a few years ago (on ext3). Up to now, I thought it only happens when I access /bigdata via NFS and do the operation from the client. But now, I have seen that it also happens when deleting files locally.
