Subject: 1.3.3 and a siezed 'dump | restore'
To: None <port-sparc@netbsd.org>
From: Rob Windsor <windsor@warthog.com>
List: port-sparc
Date: 01/30/1999 10:49:23
This is really wierd.

USER       PID %CPU %MEM   VSZ  RSS TT  STAT STARTED       TIME COMMAND
windsor    881  0.0  0.0    84    8 p3  D+   10:33AM    0:00.05 egrep 
PID|dump|restore
root       854  0.0  0.0   600   76 ??  IW   10:16AM    0:03.55 dump 0f - /usr 
root       855  0.0  0.0  4196   48 ??  I    10:16AM    2:39.19 (restore)
root       856  0.0  0.1   656   88 ??  I    10:16AM    0:12.62 dump 0f - /usr 
root       857  0.0  0.0   600   32 ??  I    10:16AM    0:29.05 dump 0f - /usr 
root       858  0.0  0.0   600   32 ??  I    10:16AM    0:28.65 dump 0f - /usr 
root       859  0.0  0.0   600   32 ??  I    10:16AM    0:28.42 dump 0f - /usr 

systat vmstat shows:

[...]
Discs  sd0  sd1  fd0                                      daefr
seeks                                                     prcfr
xfers                                                     react
Kbyte                                                     scan
  sec                                                     hdrev
                                                          intrn
Top shows:

  PID USERNAME PRI NICE   SIZE   RES STATE   TIME   WCPU    CPU COMMAND
  857 root      18   -5   600K   32K sleep   0:29  0.00%  0.00% dump
  859 root      18   -5   600K   32K sleep   0:28  0.00%  0.00% dump
  858 root      18   -5   600K   32K sleep   0:28  0.00%  0.00% dump
  856 root       2   -5   656K   88K sleep   0:12  0.00%  0.00% dump
  855 root       2    0  4196K   48K sleep   2:39  0.00%  0.00% restore
  854 root      10   -5   600K   76K sleep   0:03  0.00%  0.00% <dump>

And it has officially gone 'nighty night' on me.

My ss2 rebooted on me this morning when running my weekly "dump from one
drive and restore to another", so I thought I'd test it again.  I changed
the crontab to run it now so that I could tail the output and watch various
stats (what you see above).

While the dump was happening, I ran another app to chew up the memory
specifically to force the OS to hit swap.  The other app was completed
a few minutes before this happened.

I'm going to let this simmer for a while, I have a few errands to run today.
Does anyone have an idea on what might be causing this?  I might have to grab
the changes made to kern_exec.c and kern_fork.c to see if that fixes the
problem.

-- Rob
----------------------------------------
Internet: windsor@warthog.com
Life: Rob@Carrollton.Texas.USA.Earth

The weather is here, wish you were beautiful.