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:
# sync; df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda4 13915072 13304004 0 100% /
Any suggestions? I shut off some services/processes but not sure how to check who might be actively eating disk space.
More info
# dumpe2fs /dev/sda4 Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 884736 Block count: 3534300 Reserved block count: 176715 Free blocks: 422679 Free inodes: 520239 First block: 0 Block size: 4096 Fragment size: 4096
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Check with lsof to see if there are files held open. Space will not be freed until they are closed.
sudo /usr/sbin/lsof | grep deleted
will tell you which deleted files are still held open.
Method 2
Use lsof to find the deleted, but open, file still consuming space:
lsof | grep deleted | grep etilqs_1IlrBRwsveCCxId chrome 3446 user 128u REG 253,2 16400 2364626 /var/tmp/etilqs_1IlrBRwsveCCxId (deleted)
Find the entry in /proc/<pid>/fd/ that cooresponds to the filehandle:
ls -l /proc/3446/fd/etilqs_1IlrBRwsveCCxId lrwx------. 1 user unix 64 Feb 11 15:31 128 -> /var/tmp/etilqs_1IlrBRwsveCCxId (deleted)
Now, just cat /dev/null into the fd:
cat /dev/null > /proc/3446/fd/128
Note that the inode is still open, but now it’s 0 length
chrome 3446 user 128u REG 253,2 0 2364626 /var/tmp/etilqs_1IlrBRwsveCCxId (deleted)
Method 3
df will not show space reserved for root (even when run as root):
# df -h Filesystem Size Used Avail Use% Mounted on ... /dev/optvol 625G 607G 0 100% /opt ...
How to change “reserved block percentage”
-
Reduce reserved space to 4%
# tune2fs -m4 /dev/sda4
df -h now showed 45M free.
- Saved my files quickly
-
Put it back to 5%
# tune2fs -m5 /dev/sda4
Method 4
In Ubuntu, if you deleted files using your trash bin, your files were more than likely not be completely removed.
Even after emptying your trash your files will remain in ~/.local/share/Trash/expunged until after a reboot and maybe even longer.
I haven’t found a good reason for this, but if I run out of space, I always manually rm the expunged trash files.
Method 5
sudo lsof | grep "(deleted)$" | sed -re 's/^S+s+(S+)s+S+s+([0-9]+).*/1/fd/2/' | while read file; do sudo bash -c ": > /proc/$file"; done
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.
Method 6
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…
Method 7
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.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0