Differences between df and du -s 

Newsgroups: comp.os.linux.misc
Date: 29 Jan 2003 09:55:12 +0100
> I've had this strange problem for which I haven't been able to find an
> explanation:
>
> With "df", I saw my partition in /dev/hda7, mounted on /var, which had all
> its capacity (250 MB) used. I have a MySQL database installed (it uses the
> /var directory), and it had stopped working.
>
> Hoewever, changing to this directory, and doing du -s, showed that only 23
> or 24 MB were allocated to the filesystem. [...]
>
> Where could the problem be?

Not all the files existing are accessible from the directories!

int main()
{
    int i;
    char buffer[1024];
    int fd=open("/tmp/test",O_CREAT|O_RDWR);
    unlink("/tmp/test");
    for(i=0;i<250*1024;i++){
        write(fd,buffer,sizeof(buffer);
    }
    for(;;){
        sleep(3600);
    }
    return(0);
}
> What tools could I use to find the problem if it happens again?
lsof, in that case ------------------------------++++
                                                 ||||
[pascal@thalassa essais]$ lsof|head              VVVV
COMMAND     PID   USER   FD   TYPE     DEVICE    SIZE      NODE NAME
init          1   root  mem    REG        9,0  440536    608790 /sbin/init
do-fetchm   151   root  mem    REG        9,0  442760        28 /bin/bash

The grossest way: reboot Otherwise, if you identify the culprit: kill $pid

Pascal_Bourguignon

Differences between df and du -s 

> In any unix-like system, when a file is deleted but it is still
> opened by a process, the space is not released (and actually the process
> can continue using the file as normal).   When the process exits,
> the space is released.

Right. And the difference in du -s and df output is because df asks the filesystem (which knows about the files even though they're not listed in any directory), whereas du -s just walks the directories, so the deleted but not released files don't show up.

Ed

Differences between df and du -s 

> A process can create a file and immediately unlink it. If the process

You or someone or some program could also have rm a file which is in use. That file name is removed from the directory structure, but the inodes are not released and the file can continue using it. Eg, you might have decided that /var/log/syslog is too big and removed it, thinking that syslog would recreate the file. Instead syslogd was still connected to that file and filling it up. This is why if you look at the various logrotate scripts, they always restart the daemon after saving the log file. This kills the process which was using it, and restarts it. At the killing the old process releases the inodes of the removed file and the space is freed. When it is restarted it restarts with the new file.

Do you recall trying to "clean up" /var/log of some large file and simply rm it?

Bill Unruh

> The utilities 'lofs' and 'fuser' may also help. I can't recall which comes
> with linux distributions - possibly both.
>
> Frank Ranner