Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ames!rex!samsung!uunet!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.unix.i386
Subject: Re: Tape backup performance on 386 ISA/EISA systems
Keywords: tape, performance, 386
Message-ID: <1069@sixhub.UUCP>
Date: 4 Jun 90 01:51:21 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: davidsen@sixhub.UUCP (bill davidsen)
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 46

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:
| >
| >  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. I see
| >about 4MB overall (from the time I hit return to the time the tape is
| >rewound) on a non-fragmented f/s. At least with standard Xenix and UNIX
| >f/s there is a huge gain for backup.
| 
| 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.

  Sorry, foot in keyboard time. That's 300k/min and 4MB/min for the
fragmented and unfragmented filesystem. Once the tape stops streaming
you are in deep trouble for throughput. Even the tape is slowing things
down, the disk is the heart of the problem when it can't keep the tape
streaming. My usual solution is to take an incremental or physical
backup (raw disk to tape) and then cleanup.
| 
| If you still disagree, run the test I mentioned on a non-optimized disk
| and then run the same test after the disk has been optimized and
| report the results.  I had one other person do that and the difference
| was less than 10% which would be expected anyway due to the differences
| in file system layout (like zillions of 1 byte files vs 1 zillion byte file).

  Yeah, see above. There really is an order of magnitude penalty when
the tape stops streaming, and that happens when the disk is slow.
| 
| >  I have not been able to show degradation in performance due to
| >fragmentation of the ufa type filesystem on V.4, so perhaps this will
| >all go away in a year or so.
| 
| You probably won't see that much difference under one of the FFS's available
| for 386 unix boxes (like 386/ix, SCO Unix, ESIX).

  I haven't tried the recent versions of ESIX. The early version I tried
was quite slow, but that could have been filesystem, tuning, or
something else. I hear good things about it, so I assume that if there
was a problem in an early version it is gone now.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me