pavement

Df

From FreeBSDwiki
(Difference between revisions)
Jump to: navigation, search
(Incorrect df)
 
Line 25: Line 25:
 
  /dev/ad0s1a  132M  107M    15M    88%    /
 
  /dev/ad0s1a  132M  107M    15M    88%    /
  
== Incorrect df ==
+
== Deleting locked files ==
  
Sometimes, df reports values that are blatantly wrong.
+
Scenario:  MySQL is giving you error 28's, and you find /var is completely full.  You find that Apache's logs have grown over 200MB, so you delete them.  The 200MB this should free would put you well within limits...  but for some reason, df still reports that /var is completely full. Why?
  
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 even though you deleted the logfile, Apache still held a lock on it and thus the space cannot be reclaimed yet by the filesystem. This is not an error on [df]'s part; the space really is still being taken up until the lock is released. To fix it, you merely need to restart apache, (perhaps using [[Apachectl]])Apache then releases the log file, df shows the space returned as free, and MySQL goes back to working.
 
+
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.
+
  
 
[[Category:System Commands]]
 
[[Category:System Commands]]

Latest revision as of 03:56, 19 June 2007

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

[edit] Deleting locked files

Scenario: MySQL is giving you error 28's, and you find /var is completely full. You find that Apache's logs have grown over 200MB, so you delete them. The 200MB this should free would put you well within limits... but for some reason, df still reports that /var is completely full. Why?

The problem is that even though you deleted the logfile, Apache still held a lock on it and thus the space cannot be reclaimed yet by the filesystem. This is not an error on [df]'s part; the space really is still being taken up until the lock is released. To fix it, you merely need to restart apache, (perhaps using Apachectl). Apache then releases the log file, df shows the space returned as free, and MySQL goes back to working.

Personal tools