[comp.unix.ultrix] Is there a way to make rdump to Exabyte faster?

caroline@pangea.Stanford.EDU (Caroline Lambert) (05/08/91)

I have one Mountain FileSafe Exabyte on a DEC5000 which I use to backup
several Decs and Suns. It takes three times as long to back up 1GB on
a remote Dec as it does a remote Sun. This is becoming a problem since
there is a very small time gap between when the grad students go home
at night and when more 'normal' people come in in the morning, and the
amount of disk used is growing.

So my question is: what parameters can I use to make the backup 
		   go faster?

This is what I use to back up a Sun:
rdump 0usdbf 54000 6000 20 tapemachine:/dev/nrmt0h /filesystem

The logic behind this is that tape density is 6000 bpi, the 54000 is
the factor needed to get the right tape size, and the blocking factor
is 20 because that's the most the network can handle.

Doing a remote dump from a DEC5000 (Ultrix 4.1) I am using the 
parameters recommended by the manufacturer of the tape drive, 
for lack of anything better (there's no 'b' parameter for the ultrix rdump).
This is for a 2GB tape:
rdump 0unsdBf 346 4137733 2097152 tapemachine:/dev/nrmt0h /filesystem

which don't make very much sense at all - I thought the tape density was
6000 bpi. The backup is reasonably fast
on the machine the tape drive is on, but much slower (3-4x) for the remote
Decs. Monkeying around with the size and density doesn't make any
difference (which makes sense since I gather the machine is supposed
to be smart enough to read the density off the tape anyway).

Any ideas beyond switching the tape drive from one machine to another?
What does the 'o' argument to rdump do (the man page is
uninformative)?

--
Caroline Lambert               
Dept. of Geophysics
Stanford University	caroline@pangea.Stanford.EDU   standard disclaimer

jch@hollie.rdg.dec.com (John Haxby) (05/08/91)

In article <1991May7.170515.2915@morrow.stanford.edu>, caroline@pangea.Stanford.EDU (Caroline Lambert) writes:

|> So my question is: what parameters can I use to make the backup 
|> 		   go faster?

The trouble with the rmt protocol is that it is a stop-and-wait
protocol which effectively prevents the Exabyte from streaming.

I do a remote dump to a DAT drive (4mm instead of 8mm, and
smaller, but otherwise similar) using rsh and dd, viz

	dump Nuf - | rsh tapehost dd bs=10k of=/dev/nrmt0h conv=block

(N is the level of the dump.) It isn't as fast as it could be (the pipe and
rsh are a bit of a bottleneck), but at least the tape streams.  I get
around 140kbytes/second from a big VAX to a DECstation 5000--different
hardware, of course, will give different behaviour.

For my purposes, rsh is fast enough as I can more-or-less fill a 1Gb
tape in a couple of hours.

-- 
John Haxby, Definitively Wrong.
Digital				<jch@wessex.rdg.dec.com>
Reading, England		<...!ukc!wessex!jch>

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.

karrer@bernina.ethz.ch (Andreas Karrer) (05/08/91)

caroline@pangea.Stanford.EDU (Caroline Lambert) writes:

[...]
>Doing a remote dump from a DEC5000 (Ultrix 4.1) I am using the 
>parameters recommended by the manufacturer of the tape drive, 
>for lack of anything better (there's no 'b' parameter for the ultrix rdump).
>This is for a 2GB tape:
>rdump 0unsdBf 346 4137733 2097152 tapemachine:/dev/nrmt0h /filesystem

we don't use rdump anymore. we use basically 
dump 0uf - /dev/r<pastition> | rsh tapehost "buffer -s 126b > /dev/<exabyte>"
and get transfer rates (DECsystem 5500 -> Sun 4/490) of 220KB/s, close
to the streaming speed of the exabyte (246 KB/s ?).

buffer is a highly useful program written by Lee McLoughlin, Imperial College
(lmjm@doc.ic.ac.uk or lmjm%uk.ac.ic.doc@nsfnet-relay.ac.uk). It is
basically a "dd" that splits itself into two processes that communicate
thru shared memory and does re-blocking. we run it under SunOS 4.1.1
and Ultrix 4.[0|1].

buffer was posted to alt.sources some time back, but i can't readily find it
on any ftp site. so i put it on 
ural.ethz.ch[129.132.1.45]:software/source/buffer.tar.Z

+-----------
  Andi Karrer, Communication Systems, ETH Zuerich, Switzerland
  karrer@bernina.ethz.ch                 - terible simplifieur
  /s=karrer/ou=bernina/o=ethz/prmd=switch/admd=arcom/c=ch/