Is there a way to tell the kernel to give back the free disk space now? Like a write to something in /proc/ ? Using Ubuntu 11.10 with ext4.

This is probably an old and very repeated theme.
After hitting 0 space only noticed when my editor couldn't save source code files I have open, which to my horror now have 0 byte size in the folder listing, I went on a deleting spree.

I deleted 100's of MB of large files both from user and from root, and did some hardlinking too.

Just before I did apt-get clean there was over 900MB in /var/cache/apt/archives, now there is only 108KB:

# du
108 /var/cache/apt/archives

An hour later still no free space and cannot save my precious files opened in the editor, but notice the disparity below:

The file system frees the space immediately. However, the root-reserved blocks feature of ext[234] and how the kernel keeps open files reserved may give the appearance of lost space.
–
hhaamuMar 14 '12 at 13:34

If you have several filesystems (patitions), freeing up space in one won't do any good in the other one.
–
vonbrandFeb 4 '14 at 19:48

Why was I able to fill the partition before the "reserved" 5Go blocks reclaim themselves?
–
PsddSep 30 '14 at 15:29

Good. Showed me some mysqld locks in /tmp, but many apport-gt uses of extinct files in /var/lib/apt/lists/partial/ that apparently have been accumulating. So I might killall apport-gt but will investigate it first.
–
MarcosMar 14 '12 at 11:29

1

Marking as closest answer, although never really "gave back" the space immediately after closing file handles/processes using them. Looking for other kernel/proc/fs-based approaches.
–
MarcosNov 8 '12 at 22:00

7

You can also use lsof +L1 (select open files that have been unlinked).
–
Martin FidoMay 24 '13 at 7:07

The for root reserved space is nowadays nearly always too big. You can reduce it to some few percent. df displays the for normal user usable space. As apt runs as root, the reserved space is only useful to protect against fill-ups caused by non-root users (=normal users and services that have their own user).
–
jofelMar 14 '12 at 11:22

I agree; an mkfs these days should reserve eg. 5% or 300MB, whichever is less. Just re-tuned some of my servers to 2% and freed GBs back!
–
MarcosMar 14 '12 at 15:38

@jofel, no, it isn't. Any time you go over 90% utilization, you start getting lots of fragmentation. You need to free up some more space, not run closer to 100% utilization.
–
psusiMar 14 '12 at 15:44

@psusi You are true, thanks for your comment. But the opportunity to use (temporary) nearly all available space as normal user could be really practical and with ext4, the things are not that bad anymore, see unix.stackexchange.com/a/7965/15241
–
jofelMar 14 '12 at 17:20

I wonder if sync is of any help here — but it shouldn't be, as IIRC in most ("many"?) systems, filesystems are synced each 30 s.

I'd check the kernel log (so dmesg) to find if anything nasty is going on and run lsof to see if any big, deleted file is still open (actually, I think deleted files will be marked as so in the lsof output).

Two reasons (one of these pointed in the question you link) that may cause deleted files to release no space are

files that weren't actually deleted: you deleted a file which is hardlinked somewhere else (more precisely, you unlink()ed a file with more than one link)

files that are still open: open files are bookkept using, well, files, inodes themselves, not directory entries, if you delete the entry, the inode will remain there as long as it is still open.

But I don't know of a specific reason why that might happen with so many files...

sync never helped. As for logs, it's an Ubuntu system so it's pretty buggy, so yeah they're typically noisy. apport has be deploying often because every nightly apt-get update crashes, though /var/crash has only 77MB. Also noticed atd has flooded /var/log/syslog with repeating lines like atd[8892]: File a0015c0152ab76 is in wrong format - aborting probably since the few files in /var/spool/cron/atspool were all 0 sized, making the problem circular of course
–
MarcosMar 14 '12 at 11:41

Good point. Even though I'm one of those who live and die by the command line, and rarely use graphical file manager. Haven't yet noticed that expunged folder as a hiding place though--an Empty Trash click had always been final and returned my disk space when needed.
–
MarcosMar 14 '12 at 17:53

CentOS 6.3 also does the not-actually-emptying-trash-can-when-you-empty-trash-can thing. I couldn't find a way to reclaim the space until I just ran rm -rf ~/.local/share/Trash/expunged/. Caused much head-scratching.

Explanation:
Grep lsof output to extract only deleted files. Sed extract the process id and filedescriptor id from each line, and create a string in format {pid}/fd/{fid}. While loop and output nothing to each file, setting them to empty.