Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!news
From: Steinar.Haug@delab.sintef.no (Steinar Haug)
Newsgroups: comp.sys.hp
Subject: Re: dump aborts with 'bad sblock magic number'
Message-ID: <1991Mar25.112650*Steinar.Haug@delab.sintef.no>
Date: 25 Mar 91 10:26:50 GMT
References: <1991Mar22.160524*Steinar.Haug@elab-runit.sintef.no>
Sender: news@ugle.unit.no
Organization: SINTEF DELAB, Trondheim, Norway.
Lines: 41
In-Reply-To: Steinar.Haug@elab-runit.sintef.no's message of 22 Mar 91 16:05:24

A few days ago I reported on a problem I had when using dump to backup an
HP-97549 disk. I found the solution myself this weekend, and thought I would
share it with the net. From my original posting:

> I have a problem when using dump to backup an HP-97549 disk. The dump
> goes to an Exabyte connected to a Sun workstation. I have used dump on
> the same machine previously to backup an HP-97548 disk with no problem.
> Btw, both disks have long filename file systems. The HP is a 9000/400s
> running HP-UX 7.03.
> 
> Dump reports:
> 
> rsh faust -n /etc/dump 0usdf 90000 43200 aida:/dev/nrst8 /mnt
>   DUMP: Date of this level 0 dump: Thu Mar 21 17:14:12 1991
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /mnt to /dev/nrst8 on host aida
>   DUMP: bad sblock magic number
>   DUMP: The ENTIRE dump is aborted.

The problem was that the file system was not mentioned in /etc/checklist.
I had mounted the filesystem using 'mount /dev/dsk/1s0 /mnt' and simply
assumed that this would be okay. I have to say, though,  that the error
message given by dump is rather far off the mark... Since /etc/checklist
*is* mentioned in the man page for dump, I suppose this behavior could be
regarded as a feature, though it was not at all obvious to me.

On a related note, does anybody know of software which will allow me to
use fbackup/frecover on the HPs for remote dumps to a Sun? I assume I need
a somewhat enhanced rmt driver... Using fbackup/frecover would presuambly
give me better speed than dump/restore. Alternatively, does anybody have
a faster dump for HP-UX? On most of our Suns we see dump speeds of around
12 MByte/minute, which is close enough to the Exabyte advertised maximum
of 246 kByte/s that I'm not going to complain. On the HPs, the speed is
around 6 MByte/minute, ie. only half of the speed of dump on the Suns. I
would guess this is because Sun has done a better job of optimizing the
dump I/O behavior.

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no