Tape backup performance on 386 ISA/EISA systems

[Wm E. Davidsen Jr]

In article <1990May30.132457.6117 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:

| 1. There are no commercial disk optimzers for UNIX (at least that I know of)
| and most people, myself included, cringe at the thought of letting someone's
| program hunt around my raw disk patching things together.  I'm not saying
| that the programs are bad. I'm just saying that it will take a lot more
| than a simple post to alt.sources to get me to run one of those programs
| on my production systems.  Anyway, I can't ask people to run one when they
| may not even have it.

  True enough, but they are worth getting. Yes, I cringe when I run it,
but I take a backup first.
| 
| 2. The performance of the disk due to optimizations will probably have
| little performance effect on the overall perforance on the tape write, since
| the tape write is the limiting factor.

  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.

  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.

-- 
bill davidsen - davidsen at 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