8

When I run df it shows the root device is full.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  9.4G     0 100% /

I looked at the inode usage and there is pretty much space available for root device

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1               640K    103K    538K   16% /

But, when I run the du command, it shows I have used only 2G out of 9.9G.

ip-XXX-XXX-XXX-XXX:/$ du -xh --max-depth=1
14M ./etc
4.0K ./mnt
96K ./tmp
3.5M ./bin
0   ./sys
964K ./boot
4.0K ./srv
0   ./dev
55M ./lib
25M ./root
1.1G ./usr
4.0K ./opt
846M ./var
4.3M ./sbin
23M ./home
16K ./lost+found
0   ./proc
2.0G .

It just driving me crazy and interesting too. This is big problem for us since the root disk / is full and some of the function in our site is failing.

Please help me resolve (also understand) this problem.

Thanks.

6
  • 2
    See linux free disk space confusion and other +df +du questions at Unix & Linux. Commented Jun 30, 2011 at 7:20
  • @Gilles like you said, I ran du -x / and I see only 2G is used and I calculated the inode size which is 160M. It helped me understand the stuff but I just want to resolve this problem. Commented Jun 30, 2011 at 7:46
  • Did you run du as root? Otherwise it can only report on the files you can access. Commented Jun 30, 2011 at 7:59
  • @Gilles I am running as root Commented Jun 30, 2011 at 8:02
  • I don't have much to add here other than the great ncdu program, which helps visualize disk usage.
    – Rob
    Commented Dec 3, 2012 at 21:53

4 Answers 4

4

When files are deleted in *nix, they continue to live on disk (and take up disk space) for as long as a process has them open. It's fairly common to take advantage of this to "secure" temp files by creating them with a small size, deleting them, and then using the deleted file to store data without having to worry about other processes (easily) getting access to it, so the amount of space in deleted files can grow pretty large if, say, a temp database or multimedia editing session is being handled in this way. Another possibility for how you could have so much "lost" space would be if the system has been upgraded (multiple times) without rebooting or restarting programs, resulting in all your old .so libraries being held open by programs which were started prior to the upgrade and are still running.

df sees the space used by these files because it just looks at how much space is allocated on the device, but du doesn't see them because there aren't any corresponding directory entries.

"Hidden" used space like this can only be freed up when processes that have deleted files open close them. You can find these processes with the fuser command and terminate them (or, for many daemons, send a signal telling them to close and re-open any open files).

2
  • thanks, good info, something (more) I understand today.But to find a hidden used space, I try to run the fuser command to see all the files that are being used by a process but unlinked - I could not find any. Do you have any command or direction that leads me to find it? This is the command I use fuser -v -a / Commented Jun 30, 2011 at 11:03
  • I had to reboot it to get rid of the hidden space but I couldn't find a proper solution to remove those hidden files. Commented Jul 5, 2011 at 8:01
1

There have been times when if the disk gets full, it can then be confused till reboot/remount that the disk is still full, even when you've deleted a load of files.

2
  • I can not reboot since it's a production site. But I am looking for a solution which can help me find these hidden space and bring it back. Commented Jun 30, 2011 at 9:01
  • It maybe production but sometimes a reboot is the only answer. Thats the unfortunate problem of it being your root disk and all your OS is on it. Which is why many advocate the use of tmp, var, home etc being on other disks, as they can then be remounted. It seems to be more common that the OS doesnt realise the space is available to the root disk.
    – BugFinder
    Commented Jul 2, 2011 at 10:50
1

On my side, I simply restarted syslogd to get the disk space back. I had 3GB missing ! My server was up and running for 250 days old.

0

There is a way to cleanup space without restarting application. Here are the details:

  1. Let's say you have process foo running and creating a 2 GB file named abc.log. Now say this abc.log is deleted by someone else.

  2. Get foo's pid (let's say 123). So /proc/123/fd will show list of file descriptors opened by foo. One with abc.log will show as deleted. Let's say fd of abs.log is 111. If you run less /proc/123/fd/111, it will still show you all that 2 GB of data.

  3. Run echo " " > /proc/123/fd/111. This will overwrite the contents with an empty string. After this command if you try df it will show an additional 2 GB recovered by cleaning abc.log.

That's it. I tried this on CentOS and it works.

3
  • This is a useful thing to know. But it's not an answer to the question. Commented Dec 3, 2012 at 22:09
  • sorry my ans was more targetted towards cleaning up disk space if you know the process id who deleted the file. For this specific case, you have to go through all the files in /proc/[0-9]*/fd, grep the deleted ones, and follow the logic mentioned above. Commented Dec 5, 2012 at 22:34
  • If you are really curious which file was causing the the disk space leak, clean on deleted file at a time, check df output every time and log this information. Commented Dec 5, 2012 at 22:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .