Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!pacbell.com!decwrl!bacchus.pa.dec.com!deccrl!shlump.nac.dec.com!decuac!hussar.dco.dec.com!mjr
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Newsgroups: comp.unix.ultrix
Subject: Re: _slow_ rdump
Message-ID: <1990Oct14.205942.27205@decuac.dec.com>
Date: 14 Oct 90 20:59:42 GMT
References: <8844@pitt.UUCP>
Sender: news@decuac.dec.com (Network News)
Reply-To: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Organization: Digital Equipment Corp., Ultrix Resource Center
Lines: 22

In article <8844@pitt.UUCP> field@elvis.cs.pitt.edu (Gus) writes:

>Last night I tried dumping a 300 MB file system to tape (via rdump) from
>a Decstation 3100 (Ultrix 3.1) to a  1/4" SCSI tape drive hanging off
>a Sun3 (4.0.3).  rdump reported this would take 24 hours!

	Sometimes rdump exaggerates a little with its time estimates, but
it *IS* pretty slow. I've heard (haven't measured it) that using dd to
block the transfer can be much faster, EG:

dump 0f - /filesystem | rsh tapehost dd of=/dev/tapedrive

	I'm not sure why this is the case, to tell the truth. The rmt
protocol sends a return value after each remote read/write, which should
make it slower than the rsh/dd combination (which doesn't check errors
or returns on the write) but I can't imagine it would make it that much
slower. Has anyone ever measured this ? This is a subject of some interest
to me.

mjr.
-- 
 coffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffee