Hello, my original posting was:
________________________________________________________________________________
I recently got the following error on a SUN MP690 SunOS4.1.3
(several patches applied, like nfs ufs lock ) running 0 level dump
(dumping to a 2Gig EXabyte) again. This didn't happen to often, but often
enough to cause some extra work.
dump 0ucbdsf 126 6000 54000 /dev/nrst12 /diskc
DUMP: Date of this level 0 dump: Tue Aug 10 13:20:46 1993
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rsd7h (/diskc) to /dev/nrst12
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 1899642 blocks (927.56MB) on 0.03 tape(s).
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: bread: lseek fails
DUMP: (This should not happen)bread from /dev/rsd7h [block -1975500736]: count=7168, got=-1
DUMP: bread: lseek fails
DUMP: (This should not happen)bread from /dev/rsd7h [block -1975500722]: count=1024, got=-1
DUMP: bread: lseek fails
DUMP: (This should not happen)bread from /dev/rsd7h [block -1931192256]: count=8192, got=-1
DUMP: bread: lseek fails
DUMP: bread: lseek fails
DUMP: bread: lseek fails
...
DUMP: bread: lseek fails
DUMP: bread: lseek fails
DUMP: 10.96% done, finished in 0:40
...
Does anyone have any idea what happens. A later dump just performed fine.
Any pointers are welcome
________________________________________________________________________________
There were two possible reasons for this problem:
a) The disk is going slowly to heaven or has at least a problem
I hope is not the case, (I forgot to mention that I did a verify on the disk
the first time it happened and in a later stage a format again and no errors
appeared) but I will have a very close look on it.
b) The 0 level dump was done on in a multiuser mode and sombody was accessing
disk during the dump. This was the case (the acessing may have been an at job
running over night) Since I'm optimistic :-) I hope this will be the
solution.
But nobody actually could told me if I can trust that dump (I don't !).
Doing the dump in single user mode is not a solution either (the machine has
to run 24hrs a day so I will see if I can survive to run a dump occasionally
by hand)
Thanks to all who have replied (see the solutions above)
a)Dan A. Zambon (dzambon@afit.af.mil)
Tom Slezak (slezak@llnl.gov)
Steve Scott (sgs@hogpa.att.com)
Chris Cleary (c23cjc@kocrsv01.delcoelect.com)
Luck Lewie
Russ Poffenberger (poffen@sj.ate.slb.com)
Ray Brownrigg (ray@isor.vuw.ac.nz)
Jerry Springer
Greg Kastanek (glk@synoptics.com)
Robert Freeman
Larry Chin (larry@cchtor.cch.com)
Gary Richardson (gpr@proteon.com)
Shelley L. Shostak (sls@phy.duke.edu)
Bob Izenberg (bobi@vswr.sps.mot.com)
b)Alex Sarafin (alex.sarafian@analog.com)
Robert Wolf
Ted ??? (Sorry I deleted the header when copying it)
Glenn Satchell (glenn@uniq.com.au)
other solutions which do not apply to our system:
Dan Stromberg
Rainer Blaes (Rainer.Blaes@erno.de)
Anyway thanks to all who helped me,
Michael Fendt
________________________________________________________________________________
Michael Fendt Hackito ergo sum
ESO
Karl-Schwarzschild-Str. 2 Anonymous
85748 Garching
Germany
Tel: +49 89 32006 441
Fax: +49 89 32023 62
email: mfendt@eso.org
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:07 CDT