Hello DU users,
Problem 1.
I have just done a full restore of a 8GB swxcr RAID array.
using dump/restore and a tlz06(AS2100 128MB DU 3.2g).
I was appalled at the perfomance.
The commands were
dump -0 -b 32 /usr
restore -rv
The origional dump took three quarters of an hour to do one GB
so the entire dump took around 6 hours, the restore took 11 !!.
The restore spent 2.5 hours thrashing the disk, not reading the
tape at all, then ran out of swap space and crashed; are your kidding?
a machine with 128 MB of ram, 128MB of swap, doing nothing other
than a restore in single user mode, and it runs out of swap space???.
I added a 500MB disk for swap and things ran ok(but slowwwww) after that.
My question is; is this normal, both the swap space problem(which I really
find hard to beleive) and the restore speed?
Problem 2.
I have posted around this topic before. When I boot to the
running kernel I get a CAM error;
Feb 23 01:48:16 redgum vmunix: cam_logger: CAM_ERROR packet
Feb 23 01:48:16 redgum vmunix: cam_logger: bus 0 target 5 lun 0
Feb 23 01:48:16 redgum vmunix: ss_device_reset_done
Feb 23 01:48:16 redgum vmunix: Bus device reset has been performed
Target 5 is the newly replaced internal tape drive. Three tape drives have been
installed one after another, and all have given the same error.
BOOTING the GENVMUNIX does NOT give the error. This is surely a
software(driver?) problem. As far as I can tell it is not a hardware
problem(although I haven't ruled out bad cables)
What could be the difference between the genvmunix and the running kernel that
could result in this behaviour?. The only customisations are
maxusers 256
pseudo-device pty 256
built using doconfig
any ideas?
boc
--
------------------------------------------------------------
Brian O'Connor, Unix Systems Consultant
Latrobe University,Bendigo
boc_at_ironbark.bendigo.latrobe.edu.au
------------------------------------------------------------
Received on Mon Feb 24 1997 - 00:42:56 NZDT