Can you tell me a command to show which file in the filesystem recently grew tremendously and then went back to its original size? I tried looking into dtrace disk i/o type commands but they take time to learn.. I want to know how to detect where in the filesystem the most drastic disk usage changes recently occurred. Thanks!
---------- Post updated at 03:58 PM ---------- Previous update was at 02:38 PM ----------
Is this not possible? I was hoping it would be find with exec and some filters on it, but maybe it is way harder than that?
A process can create a file with open(), then remove the file. The process at this point now has a file which does not show up in utilities like ls, for example. The file is removed from the filesystem when the last process that has a decriptor for the file closes the descriptor. This can make it hard to find the process behind the problem. Or the cause of a huge flux in disk space.
I mention this because it sounds like you've tried a scan with find and it is not picking up really big files that come and go.
Yes Jim, that is a valid point.. If I could find out what file it is, I would have a better idea of the process.. How about a command to have any file that grows above say, 20GB reported in system log? Is that doable?
as the easier/cheaper alternative, I would recommend using disk quotas in order to block the growing of the suspicious file, thus triggering a syslog event for quota-offenders ;
now deeper (and way different) than that approach, a Dtrace probe to inspect the stat/lstat syscalls and the st_size value can spot your file, at the costs of some overhead to your overall performance, and some Dtrace programming ;
Botao, that is also a valid point, but from what I'm being told by the sysadmin, we have quotas and they are being ignored fir some reason.. this is a Mac OS X environment with disk quotas applied through the workgroup mgr util.
---------- Post updated at 11:06 AM ---------- Previous update was at 11:05 AM ----------
We have discovered that Firefox 3.5.5 was causing this problem, so I we have rolled it back. Thank for the help, I'd still be interested in any others thoughts on the issue, but it can be closed if necessary.