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% /
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.