Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have file servers which are used to store files. Files might reside there for a week, or for a year. Unfortunately, when I remove files from the server, df command doesn't reflect the freed up space. So eventually, the server gets filled up (df shows 99%), and my script doesn't send any more files there, except there might be a few dozen GB of free space on there.

I got noatime flag on the mounted partitions if that makes any difference.

share|improve this question
Is this happening on a single partition or on all partitions? – Khaled Feb 8 '11 at 7:40
Well, its happening on my main data partition, which is the only one I care about, since I only write/remove files onto it. – user11350 Feb 8 '11 at 8:09
Please enlighten me with the solution, or a link to one. – user11350 Feb 8 '11 at 8:51
What filesystem(s)? DF does a stat of the superblock, it may be that your filesystem is not updating the sb inode. Have you tried flushing cache? – beans Feb 8 '11 at 17:32
Using ext4. How do you flush caches? – user11350 Feb 8 '11 at 18:22
up vote 79 down vote accepted

Deleting the filename doesn't actually delete the file. Some other process is holding the file open, causing it to not be deleted; restart or kill that process to release the file.


lsof +L1

to find out which process is using a deleted (unlinked) file.

share|improve this answer
Files that are removed were not accessed in over a month, and the only process that accesses them is nginx, so its doubtful. – user11350 Feb 8 '11 at 8:08
+1. Also, "lsof +L1" will tell you which program is holding the files open. – pehrs Feb 8 '11 at 8:10
as root run "lsof -n | grep file," you'd be surprised at how long files can stick around due to processes keeping them open for whatever reason. If all else fails, reboot, I feel bad suggesting it but it will definitely make sure nothing is holding on to the file. Per pehrs, lsof +L1 is probably the better way to go. – ScottZ Feb 8 '11 at 8:11
That returns a single file, which is being encoded with ffmpeg. – user11350 Feb 8 '11 at 8:16
You just saved me! Deleted a 93G log file and didn't get the space back and couldn't work out why. Thanks. – Luke Cousins Apr 16 '14 at 14:14

as Ignacio mentions, deleting the file won't free the space until you delete the processes that have open handles against that file.

Nevertheless, you can reclaim the space without killing the processes. All you need to do is to remove the file descriptors.

First execute lsof | grep deleted to identify the process holding the file

[hudson@opsynxvm0055 log]$ /usr/sbin/lsof |grep deleted
java       8859   hudson    1w      REG              253,0 3662503356    7578206 /crucible/data/current/var/log/fisheye.out (deleted)

Then execute:

cd /proc/PID/fd


[hudson@opsynxvm0055 fd]$ ls -l |grep deleted
total 0
l-wx------ 1 hudson devel 64 Feb  7 11:48 1 -> /crucible/data/current/var/log/fisheye.out (deleted)

The "1" will be the file descriptor. Now type "> FD" to reclaim that space

> 1

You might need to repeat the operation if there are other processes holding the file.

share|improve this answer
what does the > FD do? – Pred Jul 6 '15 at 13:19
it removes the file descriptor – Adrián Deccico Jul 13 '15 at 1:12
does this > command have a name? i had to switch from zsh to bash in order to be able to use it. Is it possible to run it on zsh? – ariera Nov 13 '15 at 17:35

One possibility is that the file(s) you deleted have more references in the filesystem. If you've created hardlinks, several filenames will point to the same data, and the data (the actual contents) won't be marked as free/usable until all references to it has been removed. Before you delete files, either stat them (Entry named Links) or do ls -l on them (should be the second column).

If it does turn out that the files are referenced elsewhere, I guess you'll have to ls -i the file(s) to find the inode-number, and then do a find with -inum <inode-number> to find the other references to that file (you probably also want to use -mount to stay within the same filesystem as well).

share|improve this answer

The other answers are correct: If you delete a file, and space does not get freed, it's usually either because the file is still kept open, or there are other hardlinks to it.

To help in troubleshooting, use a tool that tells you where the drive space is being spent: You can use du to get an overview of where space is going. Even better, use a graphical tool like xdiskusage (there are many like this) to hunt down the culprit. xdiskusage and friends let you drill down into the biggest space hogs to find where space is going.

That way, you'll quickly find files that still occupy space because of a second hardlink. It will also show space occupied by deleted, but open files (as (permission denied), I believe, since it cannot read the file name).

share|improve this answer

Since I know a ton of you are doing this for redhat in /var and gzipping files expecting the FS to shrink, but instead it grows, just make sure you service syslog restart. and lsof -v file would show you this anyhow.

share|improve this answer
This doesn't really add much; the accepted answer covered the logic behind that in 2001. When you have 50 rep, use comments if you want to add qualifiers to the existing answers. – Andrew B Mar 23 '13 at 17:34

One more option: The disk might be full due to a process that is continuously creating data: logs, cores and the like. It is possible that space is actually being freed but is immediately filled up. I have actually seen such a case. df in this case simply doesn't give the hole picture. Use du to learn more.

share|improve this answer

I`m using EXT2, FSCK helped me in this situation. Try shudown -F now , after some restarts and fscks, I see half used space.

share|improve this answer
Dear Marcellus, your solution is encompassed by the accepted answer; and sometimes you don't want to do a reboot if you are not forced to... – Deer Hunter Jan 16 '13 at 9:31

The file is still locked by the process opening it. To free up space, do these steps:

  1. Run sudo lsof | grep deleted and see which process is holding the file. Example result:

    $ sudo lsof | grep deleted
    cron     1623 root    5u   REG   0,21        0 395919638 /tmp/tmpfPagTZ4 (deleted)
  2. Kill the process using sudo kill -9 {PID}. In above sample, the PID is 1623.

    $ sudo kill -9 1623
  3. Run df to check if space is already freed up. If it's still full, maybe you need to wait a few seconds and check again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.