Df

df is acronymic for disk free.

When this command is used with no parameters, it will display the amount of disk space free on each mounted device in a 512-byte per block count, as well as a percentage.

You may specify either a device path or plain directory path to retrieve the associated mount-point information. Also, the parameter -h may be used to have the output displayed in 'human-readable' format.

[light@splat ~]$ /bin/df
Filesystem  1K-blocks     Used   Avail Capacity  Mounted on
/dev/ad0s1a    128990   104110   14562    88%    /
/dev/ad0s1f    257998      146  237214     0%    /tmp
/dev/ad0s1g  18809884 15014076 2291018    87%    /usr
/dev/ad0s1e    257998   236788     572   100%    /var
procfs              4        4       0   100%    /proc

[light@splat ~]$ df /tmp
Filesystem  1K-blocks     Used   Avail Capacity  Mounted on
/dev/ad0s1f    257998      146  237214     0%    /tmp

[light@splat ~]$ df /dev/ad0s1f
Filesystem  1K-blocks     Used   Avail Capacity  Mounted on
/dev/ad0s1f    257998      146  237214     0%    /tmp

[light@splat ~]$ df -h /
Filesystem    Size   Used  Avail Capacity  Mounted on
/dev/ad0s1a   132M   107M    15M    88%    /

Incorrect df

Sometimes, df reports values that are blatantly wrong.

Scenario: MySQL is giving you error 28's, and you find /var is completely full. You delete the 200 MB Apache logs, which should put you well within limits... ...for some reason, df still reports that /var appears is completely full?

The problem is that Apache is still holding on to the log file, even though you deleted. Arguably this is not an error on [df]'s part; the space is still being taken up. In any case, to fix it:

If you restart apache, (perhaps using Apachectl,) Apache releases the log file, and df shows the value right. MySQL goes back to working.