On Fri, Dec 03, 1999 at 11:30:55AM +1100, Jamie Carl wrote:
| I have a compaq 20/40GB DLT Tape drive in a Compaq Proliant 7000
| running redhat 6.0 At the moment the drive 'appears' to be working
| fine, except for the fact that it takes a looooong time to do a backup.
| I recently noticed it was actually winding, then pausing, then winding,
| then pausing, constantly as it did the backup.
In short, it's not streaming.
| Is this something to do with blocksize maybe? Or is there someway i
| can implement better support for this tape drive? It doesn't seem to
| be 100% supported as when i do a 'mt status' it says the density code
| is unknown.
A bigger blocksize may help. This tends to be tunable.
Also, you want to be able to feed data to it as fast as possible.
If you're doing a backup via a pipe, eg:
tar blah blah blah... | dd bs=64k of=/dev/rmt0
You can get hung up when the pipe fills (it's only a few k).
The tar writes a chunk of data, the pipe fills, the tar blocks, the dd wakes
up and sucks out thoe few k and throws them at the tape, the tar writes again.
Quite jerky, it can be.
There's a program called "buffer" for this kind of thing:
tar ... | buffer -m 1024000 | dd ...
where the -m says what size buffer the buffer command itself uses.
Buffer sucks data like mad from the tar into memory, and in parallel
feeds it out the outgoing pipe to the dd. With a nice big buffer (eg 1meg)
this mostly stops the tar and dd from being in tiny few k lockstep and gives
much better odds of getting dd to stream.
When dd can feed lots of data to the tape it can run at constant speed,
scribbling away at tape speed. Every time it stops (because dd has no
data to send) you incur a BIG delay, because a stop is time consuming,
and some realignment takes pace as well (tiny rewinds etc).
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
Withdrawing in disgust is not the same as conceding.
- Jon Adams <[EMAIL PROTECTED]>
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
