SUMMARY: dump 0cfu tape limits.

From: Jonathan Dyke (dyke@fourier.mskcc.org)
Date: Tue Aug 24 1999 - 17:59:54 CDT


My initial message was:

I am restoring a dump tape created using : dump 0cfu on an older SunOS
4.0.3 machine.
Using the restore ifvs command, I can see ALL the files I need.
Restoring using either the:
restore rfvs or restore xfvs result in some files being restored off
tape to around 44Mb.

/dev/sd1g 272710 44153 201286 18% /home/disk1
/dev/sd2g 272710 43496 201943 18% /home/disk2
/dev/sd3g 272710 43144 202295 18% /home/disk3g

Each partition was only restored until it hit that 44Mb limit and then
restore asked for the
next volume.. although I was only using 1 volume/file system.
What might I do to grab the other files that are in the dumplist?

Thanks,
    Jon

_____________________________________________________________

The solution was given by: Michael Maciolek <mikem@ne.cohesive.com>

and thanks also goes out to: Brion Leary <brion@dia.state.ma.us>

and Tim Carlson.

When you do a "dump -c", the defaults (according to the man page)
are -d = 1000 BPI, -s = 425 feet, and -t = 9 tracks. Multiply it all
out and you get 1000 * 425 * 12 (inches/foot) * 9 = 45900000 bytes
which is in the ballpark for your 44 megabyte-or-so file size.

When dump has written 45900000 bytes (or when it's getting close) it
stops writing and prompts the user for a new tape. If dump is not
running interactively, it *can't* prompt for a new tape, so it just
dies, leaving an incomplete dump on the first tape. Here's a demo of
this behavior; note the next-to-last line when 'dump' tries to open
/dev/tty (the interactive terminal) and fails:

  DUMP: Date of this level 0 dump: Tue Aug 24 18:25:05 1999
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rsd0e (/var) to /dev/null
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 115138 blocks (56.22MB) on 1.31 tape(s).
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: Tape rewinding
  DUMP: Change Volumes: Mount volume #2
  DUMP: fopen on /dev/tty fails
  DUMP: The ENTIRE dump is aborted.

The fix (for the sake of future generations) is to override the default
parameters so they describe a tape size that's big enough to accommodate
the largest filesystem you plan on dumping. Ideally, you would specify
a size and density that match the tape device you're actually using.

(there might be such info available for various tape devices on the sun
manager's archives.)

______________________________________________________________

So when you do a restore ifs you see all the files but

it only grabs the ones within the first 45Mb of the dump

and asks for the next volume! The file size of the dump was

determined by Brion Leary using: tcopy /dev/rmt/0n.

Although I could not restore the tapes.. I will sleep at night! :)

Jonathan Dyke, Ph.D.
Department of Medical Physics/MRI
Memorial Sloan-Kettering Cancer Center
1275 York Avenue
New York, NY. 10021
(212) 639-8835 Office
(212) 717-3676 FAX



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:25 CDT