One possible reason, is that ext2/3/4 and other "Unix file-systems" reserves a certain amount of space for root - I believe the default is 5%. That way, the root-user and processes run by root still has room to maneuver, even when the system reports that the file-system is full and refuses to let normal (non-root) users write anything.
This is great for some file-systems - like / (root), /var and if you have everything on one filesystem... it may be less ideal for /home and /usr filesystems, which probably should have less reserved space (perhaps just 1% or none).
In any case, when commands like
df reports "0 bytes free" and "100% used", that doesn't include these 5% reserved for root! So while normal users are blocked, the root-user and processes running as root, may continue to write - seemingly filling the partition above 100%.
This means that the disk is not as full as you may think... But it also means that deleting files may not have as much impact as you thought it would; simply because some of the files you've deleted are files written above the 100% full limit, and thus doesn't show-up with
So if your disk is 100GB effective space,
df will show it as just 95GB. However, after you've filled these 95GB and
df shows the disk as full and the system refuses normal users to write to it, root will still be allowed to write another 5GB. If you then clean-up and delete 10GB of files,
df will ignore the 5GB that was reserved for root and only show 5GB (not 10GB) as being freed-up. So I assume that you've used some of the space reserved for root, so when you deleted 7GB, only 378MB was below the reserved limit.
You can use
tune2fs to change how much space you want to reserve for root - it should be some though (put perhaps not as much as 5%). There are also options for
mke2fs that allows you to set how much space to reserve in percent or bytes when first creating the filesystem (formatting the partition). 5% made more sense when the disks were smaller - with 500GB+ disks,
5% becomes a bit much.