ulimit hassles

Michael Borza mike at antel.uucp
Thu Feb 8 00:51:28 AEST 1990


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

In article <1611 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>In article <15142 at bfmny0.UU.NET> tneff at bfmny0.UU.NET (Tom Neff) writes:
> In article <1990Jan31.034746.8408 at virtech.uucp> cpcahil at 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 at nsfnet-relay.ac.uk

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



More information about the Comp.unix.i386 mailing list