> I ran into a problem on a server I run last night. df was reporting no space > left and services obviously stopped working. The weird thing is that when I > checked all the directories on the mount point they didn't add up to the > space allocated to the partition. It's a 37GB mounted as / with /var /bin > /boot /sbin /usr /dev /media /proc /opt and .sys
One little known fact about UNIX filesystem semantics: The filesystem driver in the kernel deletes files once their reference count reaches 0. The reference count is incremented with each hard link (i.e. directory entry referencing the file) *and* each time the file is *opened* by a process. It is perfectly legal to open a file and then delete it (from the directory entry) and yet have the file persist on disk. In that case, the file will be truly deallocated once the file handle is closed. What this means for you-- 'df' looks at how much space is left on the device while 'du' looks at how much space is used by files referenced in a directory tree. If a file is being used by a process but has been deleted, it will continue to show up in 'df' totals but not 'du' totals. You can use lsof to list all file handles open by all processes on the system and then try to figure out which of those files might be deleted. Oh, just thought of an alternative explanation... If say you have files stored under /foo/bar/mountpoint/... and then you turn around and mount a partition at /foo/bar/mountpoint, you will no longer see those files (and 'du' won't either) but they'll continue to take up space. This may be more likely in your case if you were having trouble mounting a partition at some point and some automated process went about writing junk to the parent partition. Later after you fixed your mount problem, you find you're running low on space there. Just a thought. HTH, tim _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
