Tape backup performance on 386 ISA/EISA systems

Paul De Bra debra at alice.UUCP
Sat Jun 2 01:19:52 AEST 1990


In article <1990May31.131341.15453 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
>In article <1060 at sixhub.UUCP> davidsen at sixhub.UUCP (bill davidsen) writes:
>>In article <1990May30.132457.6117 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
>>...
>>  I'm sorry, this is just totally wrong. You must never have had a
>>fragmented disk. I have seen transfer rates as low as 300kBytes/sec with
>>a fragmented disk and streaming tape which ran in fits and starts.
>>...
>300kBytes/sec = 18MB/min which is much faster than any tape backup that
>I have seen/heard was available for a 386, so there still wouldn't be enough
>gain in the backup to make that much of a difference.

I think we have to distinguish backup programs here. If you do something
like 'find . -print | cpio -ocB -C131072 > /dev/rmt/c0s0' the effect of
a fragmented disk is not substantial. It will take cpio longer to accumulate
the 1.3 megabytes (remember to add a 0 due to cpio bug) but the tape will
stream while writing the buffer.

If you use something like tar or any other program that reads and writes
small blocks you need a very fast and unfragmented disk to keep the blocks
coming at the same rate the tape drive needs them. Tape controllers have
only a small buffer usually so they really need a continuous flow of
small blocks. In general I would say that using such a backup program is
a bad idea. If you have been using tar I would suggest either adding a
pipe to dd or switching to bar.

Paul.
(debra at research.att.com)

-- 
------------------------------------------------------
|debra at research.att.com   | uunet!research!debra     |
------------------------------------------------------



More information about the Comp.unix.i386 mailing list