There seem to be two possibilities here:
- You're being confused by the (admittedly confusing) behavior of
df and root-reserved space - You deleted (unlinked) one hardlink to the files, there are more.
Personally, I suspect you're seeing #1. Details below, along with some concluding remarks.
Confusing df behavior
If you fill up a filesystem fully, as a non-root user, this is what it looks like:
Filesystem Size Used Avail Use% Mounted on /dev/md10 248M 236M 1.0K 100% /boot
but there is space reserved for root, typically 5%. If root fills it up, this is what df looks like (in the case of this tiny filesystem, it's another 13 MB):
Filesystem Size Used Avail Use% Mounted on /dev/md10 248M 248M 0 100% /boot
Note it went from 100% used to... 100% used. Despite actually being another 5% used. The Used field went up as expected, but the avail field just changed from 1K to 0.
And what happens when you remove the first 13MB of data? Well, you get back to the first output—you've freed 5%, but still at 100% in use and almost none available.
Conclusion: when you want to look at how much space you're actually freeing, look at the Used column—not Avail, not Use%.
Wasn't the last hardlink
rm doesn't actually delete files. It unlinks them—that is, removes hardlinks to them. Each hardlink gives the file one name, basically. When a file has no links left (and isn't open, etc.) then, only then, is the file actually deleted.
A file is actually uniquely identified on a filesystem, regardless of the number of names it has, by its inode number. If you knew the inode numbers for these files, you could use find -inum to find all the hardlinks to them—but you probably don't. If you have some related files to clean up, you can get the inode numbers from those using stat. You can then use find /path/to/mount -inum NUMBER to find all the hardlinks to that file (including the name you just stat'd). Also, inode numbers can be re-used once a file is actually deleted.
Remember: inode numbers are per filesystem. So two different files can be inode 42 on two different filesystems. Only on the same filesystem is inode 42 guaranteed to always be the same file. Also, inode numbers do not always work right with network filesystems or non-Unix filesystems. But you're using ext4, where the definitely do.
Other than that, you'll just have to find any other names to remove the normal ways (e.g., by looking for large things with xdiskusage as you're already doing)
General remarks
Trash folders are just directories. If they were full of junk that you didn't manage to delete, they'd show in xdiskusage.
You should consider a backup system which can better handle deleting old backups for you—doing it by hand is error-prone. Worse, it can also be forgotten, leading to backup failures—and restores are generally of recent data (e.g, accidental deletion, corrupted file, disk failure), not old data ("oh yeah, I did need that thing I deleted last year..."), so "disk full backup failed" means you're actually discarding the most valuable data (the new backup) to preserve the least valuable data (that backup from two years ago).
-m, either initially when runningmke2fsor later withtune2fs.