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 Meyer
dac@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