Ed_Meyer@mindlink.bc.ca (Ed Meyer) (04/26/91)
For anyone out in net-land experienced in SyQuest and/or SCSI devices.
Some time ago I bought a GVP SCSI + 105M Quantum and have been reasonably
pleased (except for the "dithers" every now and then) with the performance.
Since the 105M was on a hardcard, the 5 1/4 slot was available: I used it to
hold a SCSI compatible SyQuest 44MB removable media harddrive.
Backups were approximately 3-4 minutes (non-verify) for a 40MB partition.
Enabling verify approximately doubled the time for a diskcopy backup. The
backup was smooth and fast throughout the whole
diskcopy event.
Now, however, with all partitions being 70-90 % full, and after using the
SyQuest for about 14 months, I have noticed that backup times are taking longer
-- this is not unexpected. What is unexpected, though, is that as the copying
progresses, there is an increasing period of "quiet" between diskcopy reading
from the 105 and writing onto the SyQuest. This is true whether doing a non-
or verify diskcopy.
The copying times (on a per-track-basis) starts out as fast as before, but gets
longer and longer as the diskcopying event progresses. This process is
consistent and repeatable, and puzzling to me.
Anyone have insight and/or suggestions?
Ed Meyerdac@prolix.pub.uu.oz.au (Andrew Clayton) (04/30/91)
{Sigh. Oh for a working mail feed!}
In article <5642@mindlink.bc.ca>, Ed Meyer writes:
> Now, however, with all partitions being 70-90 % full, and after using the
> SyQuest for about 14 months, I have noticed that backup times are taking longer
> -- this is not unexpected. What is unexpected, though, is that as the copying
> progresses, there is an increasing period of "quiet" between diskcopy reading
> from the 105 and writing onto the SyQuest. This is true whether doing a non-
> or verify diskcopy.
How fragmented is your Quantum? When a disk is 90% full, things tend to slow
down somewhat. Following fileblocks around a fragmented disk takes up time.
Of course, I might be peeing in your ear, because you already make sure that
your HD is nicely defragged ...
I had a strange reproducable error occur yesterday on my ageing Miniscribe
71Mb (ST506 and slow as a wet week) - I had just cleaned off some 20 megs of
text archives, and thought I would have a peek at the disk fragmentation with
Quarterback Tools. On doing so, it showed me that my drive wasn't too bad [a
mere 361 'fragments' - when I did a check of the disk for integrity, it
claimed that A SEVERE ERROR WAS ENCOUNTERED ON FILE <TEXT.ANIM>. This was
quite a shock to me. I duly tried to examine the file, and my OTHER HD came up
with a READ/WRITE error trying to load up SID. I rebooted, and everything was
fine - loaded up Dpaint, loaded in text.anim, and it worked fine.
Repeating this sequence of events produced the same result, except instead of
rebooting when loading SID, I clicked the 'retry' option, and SID loaded.
Strangeness like this is something that I don't need.
Note: I'm only idly wasting time here, and specifically not saying that there
is anything wrong with Quarterback Tools - I have found QBT to be reliable and
useful, indeed, the 'Nortons Utilities' for the Amiga. Indespensible.
Dac
--
David Andrew Clayton. // _l _ _|Normally a resident at dac@prolix.pub.uu.oz.au
Canberra, Australia.\X/ (_](_l(_|But, due to circumstances beyond my control, I
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|don't RECEIVE mail at the moment. You could try
prolix!dac%eyrie@labtam.oz.au or ...!munnari!labtam!eyrie!prolix!dac |Post.Am