>>>>> "gt" == Greg Thomas <[EMAIL PROTECTED]> writes:

  gt> I've inherited a system with /var sized at about 100MB.
  gt> Needless to say it fills up quite often when spool/mail or
  gt> spool/mqueue fills up with people sending or receiving large
  gt> attachments.  Anyway, I just removed about 40MB of stuff but
  gt> when I do a df it still shows 100%.  Sometimes it will take a
  gt> minute or two for df to show the reclaimed space and sometimes
  gt> it never shows it.  I finally just did a shutdown -r now.  How
  gt> can I get the filesystem to detect the correct amount of free
  gt> space without restarting?  I'm currently running RH4.1 and have
  gt> a RH5.0 machine almost ready to take its place.


Loosely speaking there are three "parts" to a Unix file; the filename,
the inode, and the data itself.   

A directory is basically a file containing a list of names and
numbers.   The numbers are the IDs of the "inode" belonging to the
named file.  The inode contains the information about the file (For
example, the length, owner, modification time, mode, etc), but not the
file data itself.   The inode contains information that tells the
kernel where the data blocks for the file itself are.

Note that more than one directory entry can refer to the same inode.
The ln(1) command will do this (the extra entries are known as "hard
links", though they're indistinguishable from the original name, and
are just as 'real').

When you use the unlink(2) system call, for example with the rm(1)
command, that removes the specified directory entry.   If the name
being removed is the last one that refers to that inode, the file is
scheduled for deletion.

If the file is not open, it is deleted immediately.  Otherwise, the
kernel waits until the file is closed before deallocating the inode
and data blocks.    In the meantime the file still exists and can be
grown, written, and so on, but it has no name.

In your case, you unlinked 40Mb of files, but at least some of them
were still open.   Hence the disk usage stayed at 100%, and in fact
df(1) was in fact giving you the right answers.   When you shut the
machine down for a reboot, the processes who had those files open then
exited and the kernel deallocated the inodes and blocks for the open
files, freeing up disk space and reducing the percentage of disk used.

A reboot wasn't necessary.   Any method of getting those processes to
exit would have done the job just as well.


-- 
  PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
         To unsubscribe: mail [EMAIL PROTECTED] with 
                       "unsubscribe" as the Subject.

Reply via email to