|
Home > Archive > Backup Software > November 2005 > Tape drive "Shoe Shines" and Data Rates
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Tape drive "Shoe Shines" and Data Rates
|
|
| reg@yahoo.com 2005-11-08, 5:58 pm |
| Today i'm using a dlt 4000 - in the past I have used tape drives since
the old qic 40/80 days and one thing has been wrong with all of them
is that they all shoe shine - that is while a backup or restore is
going on the tape goes forward then back then forward then back every
1-3 seconds as if you were getting a shoe shine.
In the old days I was told that it was because of either a bad drive
or that the controller or drive could not keep up with the data rates.
Well here i am with my pentium 4 2.4ghz with 1gb of ram, an aha2940 uw
and my dlt4000 and i'm still doing the shoe shine. i have seen drives
like this and the old qic drives that did not do this an i am at a
loss of how to fix this.
also i just did a backup of about 10 gb and these are the results -
are these still considered normal rates and times for the amount of
data ?
Also why did the verify take 10 hrs and the backup only 3 - none of
the files were on a network drive so i'm not sure what is making this
process so slow.
Backed up 180 files in 10 directories.
Processed 10,275,841,404 bytes in 3 hours, 31 minutes, and 52
seconds.
Throughput rate: 46.3 MB/min
Verified 180 files in 10 directories.
1 file was different.
Processed 10,275,841,404 bytes in 10 hours, 2 minutes, and 45
seconds.
Throughput rate: 16.3 MB/min
| |
| Bob Willard 2005-11-08, 5:58 pm |
| reg@yahoo.com wrote:
>Today i'm using a dlt 4000 - in the past I have used tape drives since
>the old qic 40/80 days and one thing has been wrong with all of them
>is that they all shoe shine - that is while a backup or restore is
>going on the tape goes forward then back then forward then back every
>1-3 seconds as if you were getting a shoe shine.
>
>In the old days I was told that it was because of either a bad drive
>or that the controller or drive could not keep up with the data rates.
>
>Well here i am with my pentium 4 2.4ghz with 1gb of ram, an aha2940 uw
>and my dlt4000 and i'm still doing the shoe shine. i have seen drives
>like this and the old qic drives that did not do this an i am at a
>loss of how to fix this.
>
>
>also i just did a backup of about 10 gb and these are the results -
>are these still considered normal rates and times for the amount of
>data ?
>
>Also why did the verify take 10 hrs and the backup only 3 - none of
>the files were on a network drive so i'm not sure what is making this
>process so slow.
>
>
>
>Backed up 180 files in 10 directories.
>Processed 10,275,841,404 bytes in 3 hours, 31 minutes, and 52
>seconds.
>Throughput rate: 46.3 MB/min
>
>
>
>
>Verified 180 files in 10 directories.
>1 file was different.
>Processed 10,275,841,404 bytes in 10 hours, 2 minutes, and 45
>seconds.
>Throughput rate: 16.3 MB/min
>
>
>
>
One common cause of shoeshine during backup is inadequate read speed
from the HD(s). And, a faster CPU will not decrease seek time.
If your HDs are on the same SCSI bus as the DLT, then moving them to
a separate SCSI (or other) bus will help, since that will eliminate
the bus conflicts. {Alternatively, better backup code with more or
smarter buffering would also help -- but that's probably not under
your control.}
--
Cheers, Bob
| |
| reg@yahoo.com 2005-11-08, 5:58 pm |
| On Mon, 07 Nov 2005 06:06:13 -0500, Bob Willard
<BobwBSGS@TrashThis.comcast.net> wrote:
>reg@yahoo.com wrote:
>
>One common cause of shoeshine during backup is inadequate read speed
>from the HD(s). And, a faster CPU will not decrease seek time.
>
>If your HDs are on the same SCSI bus as the DLT, then moving them to
>a separate SCSI (or other) bus will help, since that will eliminate
>the bus conflicts. {Alternatively, better backup code with more or
>smarter buffering would also help -- but that's probably not under
>your control.}
Well the drives are sata and the drive on its own scsi controlller
with nothing else on the chain (and yes the dirive is terminated)
There are settings in backupexec to alllow for different block sizes
so i guess i could play with that, but other than that i dont know if
there is anything else one can do about it.
|
|
|
|
|