Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.i386
Subject: Re: Tape backup performance on 386 ISA/EISA systems
Keywords: tape, performance, 386
Message-ID: <10882@alice.UUCP>
Date: 1 Jun 90 15:19:52 GMT
References: <1990May25.123302.26061@virtech.uucp> <1990May26..841@rdk386.uucp> <1990May30.132457.6117@virtech.uucp> <1060@sixhub.UUCP> <1990May31.131341.15453@virtech.uucp>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 33

In article <1990May31.131341.15453@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>In article <1060@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:
>>In article <1990May30.132457.6117@virtech.uucp> cpcahil@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@research.att.com)

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