Common Problems
From AdminWiki
m |
|||
| Line 12: | Line 12: | ||
This can happen for example if a filesystem isn't mounted correctly during bootup and processess nevertheless write stuff to the directory, consuming diskspace on the <i>parent device</i>. | This can happen for example if a filesystem isn't mounted correctly during bootup and processess nevertheless write stuff to the directory, consuming diskspace on the <i>parent device</i>. | ||
| - | That's a bit more tricky to verify, the most direct approach would be closing all filehandles pointing to the mountpoint in question, unmount it and check the parent directory. Since this is hardly possible on production systems you can alternatively try to bind- | + | That's a bit more tricky to verify, the most direct approach would be closing all filehandles pointing to the mountpoint in question, unmount it and check the parent directory. Since this is hardly possible on production systems you can alternatively try to bind-mount the parent directory to another path and then verify the contents of the directory, since the "overlayed" directories of other mountpoints won't be seen there. |
Here's an example for Linux, given that the mountpoint you suspect of masking files on the rootfilesystem is <tt>/home</tt>: | Here's an example for Linux, given that the mountpoint you suspect of masking files on the rootfilesystem is <tt>/home</tt>: | ||
Latest revision as of 15:04, 22 August 2006
My diskspace is gone!
If du -x doesn't agree with df over the used diskspace two things might've happened:
- You've gotten open filehandles to deleted files.
Easy to verify with a lsof -n | grep deleted. Restart the affected process and the problem should be resolved.
- You've got files left in mount-point directories on the "parent device"
This can happen for example if a filesystem isn't mounted correctly during bootup and processess nevertheless write stuff to the directory, consuming diskspace on the parent device.
That's a bit more tricky to verify, the most direct approach would be closing all filehandles pointing to the mountpoint in question, unmount it and check the parent directory. Since this is hardly possible on production systems you can alternatively try to bind-mount the parent directory to another path and then verify the contents of the directory, since the "overlayed" directories of other mountpoints won't be seen there.
Here's an example for Linux, given that the mountpoint you suspect of masking files on the rootfilesystem is /home:
server:/mnt# mount --bind / /mnt/root/ server:/mnt# cd /mnt/root/home server:/mnt# ls <delete (old?) files if they should exist> umount /mnt/root
The same approach should work on other unices too, with different mount parameters though.
