Hi...
We have two alphaserver-4100's connected by UTP and by memory channel
(they are TRUcluster nodes). 1gb memory, 2 x 533 CPU's each. One has a
tl891 with a single TZ89 tape connected locally. The other does not
have a tape.
I'm trying to backup /, /usr etc from the system without the tape to the
system with it so I can install jumbo patch 2 and latest TRUcluster
patches (already installed on host withtape).
I'm using the following:
vdump -0 -b 60 -f - / | rsh withtape dd of=/dev/nrmt0h bs=60k
where withtape is the hostname of the system with the tape.
This seems to start off fine but seems to get progressively slower and
slower. Its run for about 30 minutes and is only 41% completed:
#vdump -0 -b 60 -f - / | rsh montst1 dd of=/dev/nrmt0h bs=60
path : /
dev/fset : root_domain#root
type : advfs
advfs id : 0x3626f1bc.000e7f04.1
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 97897754 bytes, 182 directories, 2223 files
vdump: Dumping regular files
vdump: Status at Tue Dec 8 10:12:57 1998
vdump: Dumped 6663249 of 97897754 bytes; 6.8% completed
vdump: Dumped 74 of 182 directories; 40.7% completed
vdump: Dumped 1273 of 2223 files; 57.3% completed
vdump: Status at Tue Dec 8 10:17:58 1998
vdump: Dumped 13191008 of 97897754 bytes; 13.5% completed
vdump: Dumped 81 of 182 directories; 44.5% completed
vdump: Dumped 1445 of 2223 files; 65.0% completed
vdump: Status at Tue Dec 8 10:23:35 1998
vdump: Dumped 20017122 of 97897754 bytes; 20.4% completed
vdump: Dumped 115 of 182 directories; 63.2% completed
vdump: Dumped 1851 of 2223 files; 83.3% completed
vdump: Status at Tue Dec 8 10:34:07 1998
vdump: Dumped 34791602 of 97897754 bytes; 35.5% completed
vdump: Dumped 115 of 182 directories; 63.2% completed
vdump: Dumped 1856 of 2223 files; 83.5% completed
vdump: Status at Tue Dec 8 10:39:09 1998
vdump: Dumped 40997904 of 97897754 bytes; 41.9% completed
vdump: Dumped 121 of 182 directories; 66.5% completed
vdump: Dumped 1970 of 2223 files; 88.6% completed
Theres nothing in the syslog.log or daemon.log to indicate any problems.
I do see the following displayed over and over again on the console and
in the kern.log file though:
rmerror_int: caller = 0xfffffc00005da51c, phys_rail = 0, error_type =
0x20000000
rmerror_int: Error_count = 98 phys_rail = 0 Err_reg = 0x20000000 Node =
0, lbol7
ccomsub: state change: run 84 new 99 fixed 98 cpu 1
ccomsub: state change detected by this node via callback
ccomsub: state change detected via remote node 1
ccomsub: state change: end 84 new 99 fixed 99 cpu 1
rmerror_int: caller = 0xfffffc00005da51c, phys_rail = 0, error_type =
0x20000000
rmerror_int: Error_count = 99 phys_rail = 0 Err_reg = 0x20000000 Node =
0, lbol7
ccomsub: state change: run 85 new 100 fixed 99 cpu 1
ccomsub: state change detected by this node via callback
ccomsub: state change detected via remote node 1
ccomsub: state change: end 85 new 100 fixed 100 cpu 1
I dont know if this relates to the problem or if just coincidental (I
would like to know if this represents a problem though).
pmgr shows the 'dd' process at the top of the list and using 16% - 353
cpu seconds and increasing. It seems to spend longer and longer in a
wait state though.
pmgr shows between 15 & 20 tcp segments received and this stays pretty
constant.
A vdump backup of / to a local TL891/TZ89 on withtape takes less than 5
minutes to complete. I've still got to do /usr and I need to know why
this is running so slowly.
Any ideas would be appreciated.
best regards - Tony
+-----------------------------------------------------------------+
| TONY MILLER - Systems Projects - VODAFONE LTD, Derby House, |
| Newbury Business Park, Newbury, Berkshire. |
+-------------+---------------------------------------------------+
| Phone | 01635-507687(local) |
| Work email | ANTHONY.MILLER_at_VF.VODAFONE.CO.UK |
| X.400 | G=ANTHONY; S=MILLER; C=GB; A=GOLD 400; P=VODAFONE |
| FAX | 01635-506709(local) |
+-------------+---------------------------------------------------+
Disclaimer: Opinions expressed in this mail are my own and do not
reflect the company view unless explicitly stated. The information
is provided on an 'as is' basis and no responsibility is accepted for
any system damage howsoever caused.
Received on Tue Dec 08 1998 - 11:14:43 NZDT