bad readable DLT tape

Hi,

I have a DLT tape which is cannot be read efficiently anymore. When
restoring it using tar the tape drive does not stream, i. e. it permanently
spools around, forward, backward, and so on.

After hours I get input/output errors.

My question:

Why does the drive spool around for hours? Assuming that the tape is damaged
at some sections, then it should stream normally (without changing the
directon all the time) at other sections. What I expected is the tape
streaming normally after it has passed the bad sections. But this tape does
never stream normally. Why can this be?

Thanks
Magnus

On 20-Apr-2009, Magnus Warker wrote:

I have a DLT tape which is cannot be read efficiently anymore. When
restoring it using tar the tape drive does not stream, i. e. it
permanently
spools around, forward, backward, and so on.

After hours I get input/output errors.

My question:

Why does the drive spool around for hours? Assuming that the tape is
damaged
at some sections, then it should stream normally (without changing the
directon all the time) at other sections. What I expected is the tape
streaming normally after it has passed the bad sections. But this tape
does
never stream normally. Why can this be?

Did the drive ever work OK in the system in which you are now
using it?
If there are read errors, the tape will continuosly "shoe shine" trying
to fruitlessly read the data with the erronious block checksum.
One bad checksum, and the whole file of many blocks becomes
unreadable.
Causes, bad storage of the tape, it gradually gets erased,
particularly if nor rewound. Print through can occur between
layers if not regularly rewound end to end.
Then there are physical causes, like tape head azimuth
alignment, processors and electronics not fast enough,
which is why I asked did it ever work in the same system?
It's a bit like trying to view 10 years old or more VHS tapes in
a different machine to the one they were recorded on.
My old Star Trek tapes recorded wnen the series first
aired are almost unreadable now.

Thank you! Yes, it already worked in the same environment.

Reading your post it seems that there could be some chance when totally
rewinding the tape.

Well, I already tried a mt -f /dev/st0 retension, but the drive does
nothing.

Should I spent further time in getting the retension to work? Is there any
hope? :-)

Magnus

Magnus Warker wrote:
Thank you! Yes, it already worked in the same environment.

Reading your post it seems that there could be some chance when totally
rewinding the tape.

Well, I already tried a mt -f /dev/st0 retension, but the drive does
nothing.

Should I spent further time in getting the retension to work? Is there any
hope? :-)

I've gotten DDS tapes to read properly after doing a couple of rounds of
retension. Never tried with DLT. Give it a shot, can't hurt.

Yousuf Khan

Ok, thanks for the hopes! :-)

So why does my drive ignore when I say mt -f /dev/st0 retension?

Magnus

In article , Magnus Warker
writes

Well, I already tried a mt -f /dev/st0 retension, but the drive does
nothing.

First of all, if you care about the data on the tape, write protect it
using the little slider switch on the front.

Retension isn't supported on some drives, DLT being among them. Try

mt -f /dev/st0 seod

to seek to end of data then rewind.

What are the drive and cartridge? DLT III, IIIXT, IV?

I assume you're using Linux. If you haven't already, install the mt-st
package, copy stinit.def from whereever it's been plonked to /etc, then
do a stinit -v. All as root.

Examine the output of stinit -v and see if it identifies the drive and
configures it. Then try reading your tape again.

--
(\__/)
(='.'=) Bunny says Windows 7 is Vi$ta reloaded.
(")_(") http://imgs.xkcd.com/comics/windows_7.png

Mike Tomlinson wrote:

Retension isn't supported on some drives, DLT being among them. Try
mt -f /dev/st0 seod
to seek to end of data then rewind.

I did this and the tape was rewinded.

What are the drive and cartridge? DLT III, IIIXT, IV?

It's a DLT IV drive.

I assume you're using Linux.

Debian Etch.

If you haven't already, install the mt-st package, copy stinit.def
from whereever it's been plonked to /etc,

I had it and stinit.def was already located in /etc.

then do a stinit -v. All as root.

stinit, processing tape 0
The manufacturer is 'BNCHMARK', product is 'DLT1', and revision '5032'.
Warning: No modes in definition for ('', '', '').
Can't find defaults for tape number 0.
Initialized 0 tape devices.

Examine the output of stinit -v and see if it identifies the drive and
configures it.

Well, looks good, but what about the warning?

Then try reading your tape again.

It seems that there is no change. It is still spooling around like hell.

Magnus

In article , Magnus Warker
writes


It's a DLT IV drive.

Are you sure? That's not what the output of stinit -v says. It's a DLT1/VS80
drive. That only supports DLTIV cartridges. DLTIII and IIIXT cartridges are not
supported. What cartridge are you using?

If it's a DLTiV cartridge, was the cartridge you're using written on that
particular drive? IME, DLTIV cartridges are usually written on DLT7000 (35/70GB)
drives, and a google suggests that the DLT1 will read tapes written on a DLT4000,
but NOT those written on a DLT7000.

Is it this drive?

http://www.sprague-magnetics.com/library/dlt1ds.pdf

stinit, processing tape 0
The manufacturer is 'BNCHMARK', product is 'DLT1', and revision '5032'.

Those values are read directly from the drive, and it's claiming to be a Benchmark
DLT1. The manual for this is available at

http://downloads.quantum.com/dlt1/DLT1InstOpGuide.pdf

Warning: No modes in definition for ('', '', '').
Can't find defaults for tape number 0.
Initialized 0 tape devices.

stinit.def has no entries for the Benchmark DLT1, so it cannot be correctly
configured.

Your next step is to find a stanza for the DLT1 and copy it to stinit.def. I
recommend you read

http://downloads.quantum.com/sdlt320/6464215011.pdf

Try adding the following to the end of stinit.def and re-running stinit -v.

drive-buffering=1
scsi2logical=1
no-wait=0
buffering=0
async-writes=0
read-ahead=1
two-fms=0
auto-lock=0
fast-eom=1
can-bsr=1
noblklimits=0
#BNCHMARK VS80
manufacturer=BNCHMARK model="DLT1" {
timeout=180
long-timeout=14400
can-partitions=0
mode1 blocksize=0 density=0x41 compression=0 # VS80 density, compression off
mode2 blocksize=0 density=0x41 compression=1 # VS80 density, compression on
mode3 blocksize=0 density=0x41 compression=0 # DLT8000 density, compression off
mode4 blocksize=0 density=0x41 compression=1 # DLT8000 density, compression on
}

Watch for line breaks when copying and pasting, and don't omit the final }.

You're looking for the line "Initialized 1 tape device" after stinit identifies the
Benchmark DLT1. Then try re-reading your tape.

--
(\__/)
(='.'=) Bunny says Windows 7 is Vi$ta reloaded.
(")_(") http://imgs.xkcd.com/comics/windows_7.png

It's a DLT IV drive.
Are you sure? That's not what the output of stinit -v says. It's a
DLT1/VS80
drive. That only supports DLTIV cartridges.
DLTIII and IIIXT cartridges
are not
supported. What cartridge are you using?

Well, I dealt with these things when I bought the drive and I've forgotten
the details of the drive.

But I am using DLT IV cardriges all the time and all but this one work fine.

If it's a DLTiV cartridge, was the cartridge you're using written on that
particular drive?

Yes!

IME, DLTIV cartridges are usually written on DLT7000
(35/70GB) drives, and a google suggests that the DLT1 will read tapes
written on a DLT4000, but NOT those written on a DLT7000.

I have about 20 DLT IV cardridges, all of the same type and manufacturer.
The bad tape we are talking about is the only one. So I conclude that the
drive/tape combination is ok.

Is it this drive?
http://www.sprague-magnetics.com/library/dlt1ds.pdf

No. My drive is an internal drive and occupies one 5.25" slot.

stinit.def has no entries for the Benchmark DLT1, so it cannot be
correctly configured.

This sounds interesting. I wonder, if this is the reason why the cardridge
cannot be read correctly, then why doesn't this affect all the other tapes?

Try adding the following to the end of stinit.def and re-running stinit
-v.

Looks better:

stinit, processing tape 0
The manufacturer is 'BNCHMARK', product is 'DLT1', and revision '5032'.

stinit, processing tape 1
Initialized 1 tape device.

Then try re-reading your tape.

It is still spooling, but something changed...

It is still spooling, but something changed...

Well, it read about 17 G. This is more than it read ever since I initially
wrote this posting. There still were some read errors, but - with your
help - the drive went on and read more and more.

This result is ok for me. Maybe there are some files that are lost, but the
big part is saved.

I think I'll say goodbye to tape drives and use mirrored disks instead.

Thank you very much
Magnus