disk diagnostics

[Bill Hacker]

d1789831d5 at xxxxxxxxxxxxxx>	 <44c7de28$0$775$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <8613c4330607270106h7f870523vd4a0e03c26cb541b at xxxxxxxxxxxxxx>
In-Reply-To: <8613c4330607270106h7f870523vd4a0e03c26cb541b at xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 40
Message-ID: <44c88b89$0$777$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 69.175.228.110
X-Trace: 1153993609 crater_reader.dragonflybsd.org 777 69.175.228.110
Xref: crater_reader.dragonflybsd.org dragonfly.users:6549

Pieter Dumon wrote:

> On 7/26/06, Bill Hacker <wbh at xxxxxxxxxxxxx> wrote:
> 
>> complete in *seconds* what you are reporting in *minutes*.
> 
> that's what I thought too.
> 
>> Something just has to be wrong with your set up.
> 
> yep, and I'd like to find out what.
> 
> Below are some logs.
> Pieter
> 
*SNIP*
> 
>> time rm -rf world_i386
> 
> 0.070u 0.476s 20:11.87 0.0%     313+264k 7+54102io 0pf+0w
> 

"The time utility executes and times the specified utility.  After the
      utility finishes, time writes to the standard error stream, (in seconds):
      the total time elapsed, the time used to execute the utility process and
      the time consumed by system overhead."

(not necessarily in that order?)

Am I wrong in interpreting that said act took 7 1/100's of a second of CPU time 
for itself, needed just under half a second of system overhead, but needed 20+ 
minutes end-to-end to complete by the wall-clock?

'To be determined' if it was awaiting I/O, or if something else was denying it a 
place to sit down and eat its hamburger.

What do you see on untarring the DFLY iso?

Bill