Michael Stone wrote: > songbird wrote: >>Roberto C Sánchez wrote: >>> It might also indicate files that exist (i.e., occupy blocks) without >>> having directory entries. For example, this is the case when a program >>> creates a temporary file, gets the descritor back from the syscall, then >>> immediatley calls unlink on it. The file descriptor is still active and >>> the file can be written/read with the descriptor reference, but the file >>> cannot be seen with 'ls' and, as I recall, it will not show up in the >>> calculation made by 'du'. The calculation made by 'df' will still be >>> accurate, though. >> >> wouldn't fsck clean that up? > > not if the program is still running; it's not an error condition. the > only case where fsck would help is if the whole machine crashed.
i should have noted that i would likely have killed off processes and unmounted the file system before fsck'ing it. > the traditional gotcha for "nonexistent file taking up space" is > something generating a large log file, when someone tries to free the > space by deleting the file. if the program writing it is still running, > the file is gone but the space won't be freed until the program lets go > of the file. lsof has a "deleted" indicator which can identify this. *nods* songbird