On Mon, 2009-01-12 at 23:31 +0100, Kai Schaetzl wrote: > William L. Maltby wrote on Mon, 12 Jan 2009 14:08:40 -0500: > > > The best way is to install and use the System Activity Reporting (SAR) > > system. > > AFAIK, it won't show any file-specific stuff. It's been so long, I don't remember now. But I believe you are correct. Admitting that, it still can be useful in that you can detect times and processes and loads occurring. Then if the update/access times are maintained in the FS (not everyone enables access times) you have a good starting point to "finger" the problem processes, users and files. Of course, I don't have to do that anymore. :-)) So I can make it sound a lot easier than it really is. But I do recall that tracking these source of these sorts of problems was a (sometimes) tedious and convoluted task. Back then we didn't have a lot of tools other than SAR. It still can be useful if no one bumps into a good tool for the OP to try. But, depending on the complexity and volumes of users, files, ... it might be fairly quick or very tedious. Of course, a very tight loop of "lsof" might provide what is really needed, but I have no idea of the load that might place on the system, the volume of output that may be generated, ... Presuming a large site, SAR _may_ provide a starting point allowing a substantial reduction in the quantity of output the OP may need to examine or may reduce potential load by allowing targeting of specific times, users, processes or whatnot. That's the great thing about debugging with incomplete information: everything is possible and fun! :-) > > Kai > -- Bill