Path: utzoo!utgpu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!geac!maccs!antel!mike
From: mike@antel.uucp (Michael Borza)
Newsgroups: comp.unix.i386
Subject: Re: ulimit hassles
Message-ID: <1990Feb7.135128.17335@antel.uucp>
Date: 7 Feb 90 13:51:28 GMT
References: <1611@aber-cs.UUCP>
Reply-To: mike@antel.uucp (Michael Borza)
Organization: Antel Optronics Inc., Burlington, Ontario, Canada
Lines: 49

[sorry if I've got the quoting wrong here-- m.b.]

In article <1611@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>In article <15142@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
> In article <1990Jan31.034746.8408@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>>>BTW - when I use this kind of backup I use the following:
>>>
>>>	find ... | cpio ... | compress | dd of=/dev/rmt0 obs=2048k
>>>
>>>This will run much faster and most of the time will use less space on 
>>>the tape since it will stream 2MB segments.	
>
>comp.sources.misc) or, even faster, my own 'team' (which has
>been posted to alt.sources; a slightly improved version will be
>submitted to comp.sources.misc, so don't ask me for a copy
.... looking forward to seeing it ....

>>>Actually on my box, using "bs=2048k" (both input and output) rather
>>>than just "obs=2048k" (output) runs even faster.  It seems as though
>>>with the one block size and no conversion, 'dd' reads and writes
>>>simultaneously with good efficiency.
>
>Using 'obs' is a bad idea; 'dd' will allocate *two* buffers,
>one 'ibs' (default 512?) bytes long, and the other 'obs' bytes
>long, and *copy* between the two before writing. If you use
>'bs', 'dd' just allocate one buffer, and this is vastly faster.

Actually, this seems to be very machine dependent.  On my 20 MHz machine
(10 MB of memory, no caching, ESDI disk system, Everex tape controller,
Archive tape drive), `dd bs=1024k' gives very poor performance, as does
`dd' with the default buffer sizes.  `dd ibs=1024k obs=1024k' gives much
better performance, keeping the tape streaming about 80% of the time.
The all time best performance, though, is `dd obs=1024k', using the
default input buffer size for tape writes.  On my machine, this keeps
the tape streaming >90% of the time the drive motor's running.  (Reading
from the tape, ibs is substituted for obs, naturally.)

It appears that the situation is not so clear-cut as it might first
appear.  I'd say that some experimentation with particular hardware is
in order to find what works best on a given system.

>Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk

mike borza.
-- 
Michael Borza              Antel Optronics Inc.
(416)335-5507              3325B Mainway, Burlington, Ont., Canada  L7M 1A6
work: mike@antel.UUCP  or  uunet!utai!utgpu!maccs!antel!mike
home: mike@boopsy.UUCP  or  uunet!utai!utgpu!maccs!boopsy!mike