Subject: Re: ccd again
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Tom T. Thai <email@example.com>
Date: 06/13/1997 20:28:57
Thanks for the tip.. i still have lots to learn so I really appreciate
good directions. I will try that method.
On Fri, 13 Jun 1997, Jonathan Stone wrote:
> >I did some tests on the ccd partition again. I filled it up with small
> >size files to about 90% and did rm -rf in that filesystem:
> >the deletion of files and directories was pretty fast all the way down to
> >about 40% and it crawed after that... from 40% to current 7% it took over
> >3 hours now.. doesn't seem normal.
> That's a bug. A performance bug. That's almost certainly enough to
> let soemeone else and replicate the bug, and thus find it. But that
> job would be much easier if you could do a kernel profiling run.
> That would tell us at least where the time is being mis-spent:
> * take your existing kernel config.
> * create a new kernel directory.
> * run `config' there with your usual arguments, but with the `-p' flag, too.
> (if you want to regularly keep around a kernel with profiling,
> adding a profile option to the config file is probably safer).
> * Boot the kernel with profiling enabled.
> * Run long enough to get to a point where the performance bug
> is showing up.
> In this case, it's definitely happened by the time you've
> removed 40% of the files from your ccd filesystem.
> * Do kgmon -r -b when you get to that point.
> (in this case, 40% free).
> * Do kgmon -p after several minutes, preferably about half an hour,
> if possible.
> * Then send the output of `gprof /netbsd gmon.out' with a
> PR describing the problem, and a description or copy of
> your kernel config file.
> That would make the problem *much* easier to debug. Whoever looks at
> this could build a profiling kernel themselves, but if there's
> something odd about your setup -- like the specific performance
> mismatch of disks in your CCD, or an unusual set of config options --
> the problem may not be easy to duplicate.
> Tom, this isn't a complaint about how you've described your bug: your
> report of the performance anomaly was great and to the point. But
> maybe this will help you and others produce even better bug reports
> about future performance problems.
> And of course, better bug reporting means quicker fixes :).
Thomas T. Thai Infomedia Interactive Communications
firstname.lastname@example.org TEL 612.376.9090 * FAX 612.376.9087