Summary: Strange dump behaviour

From: mfendt@eso.org
Date: Wed Aug 18 1993 - 20:47:14 CDT


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