[ Summary: dump to stdout fails under DU 4.0c ]
We do backups by having the system to which our DLT drive
is attached perform a sequence of
rsh host dump -0uf - filesystem | wrtp bufsize
(where the "wrtp" program is a tiny home-brew job which
buffers things from stdin, necessary because of possible
short reads from stdin).
This scheme has always worked fine; our remote hosts are
a mix of DUnix, IRIX, SunOS, and Solaris systems. Or to
put it more accurately, everything worked find until we
installed our first DU v4 systems.
With DU 3.2c, we see the following output from dump:
dump: Dumping from host caribou
dump: Date of this level 0 dump: Thu Aug 07 09:00:53 1997 EDT
dump: Date of last level 0 dump: the start of the epoch
dump: Dumping /dev/rrz0h (/home) to standard output
dump: Mapping (Pass I) [regular files]
dump: Mapping (Pass II) [directories]
dump: Estimate: 194338 tape blocks on 0.00 volume(s)
dump: Dumping (Pass III) [directories]
dump: 0.26% done -- finished in 00:19
dump: Dumping (Pass IV) [regular files]
dump: 93.29% done -- finished in 00:00
dump: Actual: 194447 tape blocks on 1 volume(s)
dump: Level 0 dump on Thu Aug 07 09:00:53 1997 EDT
dump: Dump completed at Thu Aug 07 09:06:25 1997 EDT
But on our 4.0c systems, we see this:
dump: Dumping from host bat
dump: Date of this level 0 dump: Thu Aug 7 08:52:44 1997 EDT
dump: Date of last level 0 dump: the start of the epoch
dump: Dumping /dev/rrz16h (/home) to standard output
dump: Mapping (Pass I) [regular files]
dump: Mapping (Pass II) [directories]
dump: Estimate: 533207 tape blocks on disk
The available blocks(0),is less than the estimated blocks(533207)
Dump is being aborted
dump: SIGTERM received
dump: The ENTIRE dump is aborted
It seems that dump is trying (and failing) to get information
about the capacity of the output device, even though output is
going to stdout. It thus assumes that the capacity is zero,
and therefore too small to hold the output, and it aborts.
I maintain that this is clearly a bug. I suppose that it should
be possible to kludge around this by using various dump options
to pretend that the tape is so many feet long, and has such and
such a density, to fool dump into thinking that it's writing to
a long-enough hunk of tape.
But this seems rather ugly and contrived. Is there anything in
the way of a more elegant workaround? (And has DEC acknowledged
that this is a bug, with a promise to fix it soon?)
One related thought: If I were to grab /usr/sbin/dump from one
of our 3.2c systems, is there any reason that it wouldn't work
under DU 4.0c?
PS: Curiously, the v4 man page for restore still suggests that
one can use the standard
dump -0f - /usr | (cd /mnt; restore -xf -)
pipeline to copy the contents of one filesystem to another. In
view of the fact that this gets used so often, it seems rather
surprising that nobody (at Digital, or at v4 field test sites)
discovered this bug.
Mark Bartelt 416/978-5619
Canadian Institute for mark_at_cita.utoronto.ca
Theoretical Astrophysics
http://www.cita.utoronto.ca/~mark
"Nur eine Waffel taugt!" -- Parsifal, in an Eggo commercial
Received on Thu Aug 07 1997 - 17:09:08 NZST