SureStore DAT 24 tape drive problem

[Wei_10]

I have an HP SureStore tape drive, which has been installed by someone else, on a Windows system. Now I have moved it onto a Linux system running Gentoo. I have had it working fine for a few weeks. Then all of a sudden, it started to have problems. Here is the error message from a backup session:

/bin/tar: /dev/nst0: Wrote only 0 of 10240 bytes
/bin/tar: Error is not recoverable: exiting now

I suspected that the drive needs cleaning as I have read about it being picky about being cleaned regularly. But it won't take a cleaning tape. I put a new one in, the "tape" light on the front panel flicks for a few seconds and then the tape is ejected.

Any help would be greately appreciated. Thanks in advance here.

[Vernon Brown_4]

You could try to read a backup that went successfully. Might narrow the possibilities. Could be driver, drive, cabling, or trash in the read heads.

Double check your tape media; I have made the error in the past of purchasing almost the right media :o)

[Martin P.J. Zinser]

Hello Wei,

I can confirm that DAT drives are picky about being cleaned regularly. How long does it take the cleaning tape? If a "few" seconds means something like 30 or so this is expected behaviour for a cleaning cycle. Did you retry using the tape after cleaning? Else, since this most probably is an external device, checking all the connectors/terminators would be high on my list.

Greetings, Martin

[Wei_10]

Thanks for your responses.

Martin said: "I can confirm that DAT drives are picky about being cleaned regularly. How long does it take the cleaning tape? If a "few" seconds means something like 30 or so this is expected behaviour for a cleaning cycle. Did you retry using the tape after cleaning? Else, since this most probably is an external device, checking all the connectors/terminators would be high on my list."

Your response made me believe it is a cleaning problem.

By "a few seconds" I meant about 5 seconds, definitely not 30. Besides, there is a "clean" LED on the front panel, which did not even flick during the whole process.

I did try using the tape, which I found out was partially written -- I mean the previous day's backup was not a total failure, but failed after some 14,000+ blocks.

And this happens to be an internal tape drive. :-) And I don't think anyone has even moved the machine a bit since I put the tape drive in it -- which had worked for a while, by the way.

[Brice_3]

tar and most of other linux backup commands by default use block size 10K. In windows, we can also specify the block size, usually it's not 10K. So when you move the drive from Windows box to Linux box, you can either:

1, when using tar, always use -b option specify block size.

or

2, change device node to use 10K block size using command:
mt -f /dev/st0 setblk 10240

[Wei_10]

Thanks, Brice, for your response.

I don't quite understnad, though. Are you suggesting that I need to do a "mt -f /dev/st0 setblk 10240" to set the block size? However, the error I received from tar said it "Wrote only 0 of 10240 bytes". I took that as tar tried to write a 10K block but only wrote 0.

Well, I will add that command to my backup script anyway. I will report the result later.

[Martin P.J. Zinser]

Hello Wei,

one thing I would still try is to see if you still can read data with this drive (do not use a tape with important data for this test!!!). If that also fails, you might face the fact that the drive is actually broken.

Greetings, Martin

[Brice_3]

Hi Wei,

If you use "mt -f /dev/st0 setblk 10240", execute it once should be good enough. Hope it works.

Also, HP has a diagnostic utility called Library and Tape Tools, which you can use to run diag and upgrade firmware on tape drive. You can download it from:

http://www.hp.com/support/tapetools/

It support RH linux 7.0 and above. It doesn't work well on SuSE Linux. Which distro are you using?

Brice

[Wei_10]

Reporting back. :-) Thanks to everyone who helped.

Brice:

I have set the block size to 10K and here is the result from "mt status":

# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=1, block number=0, partition=0.
Tape block size 10240 bytes. Density code 0x25 (DDS-3).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN

But I still get the same error message from tar.


Martin:

Yes, I am still able to read from one tape that is known with a good backup done days ago.


What I do as a daily cron job is to run tar to dump the whole samba directory onto the tape, then run tar again to do a check on the tape. Here is a report from yesterday from the script:

Fri Feb 27 01:00:00 EST 2004 Backup started
/bin/tar: /dev/nst0: Wrote only 0 of 10240 bytes
/bin/tar: Error is not recoverable: exiting now
Fri Feb 27 04:26:37 EST 2004 Backup completed.
Fri Feb 27 04:26:37 EST 2004 Current tape position: At block 1498164.
/bin/tar: Unexpected EOF in archive
/bin/tar: Error is not recoverable: exiting now
Fri Feb 27 07:52:13 EST 2004 Current tape position: At block 1498164.

[Wei_10]

Brice:

Thanks for the pointer to tapetool. I have downloaded but not tried it yet. I need to get "rpm" installed first -- I am using gentoo.

[Martin P.J. Zinser]

Hello Wei,

since you can read old tapes, we at least know the drive is not totally broken. Next step would be to exclude any potential problems with changed tapes. If you do have an old scratch tape that you know you could write too before, try if that can be rewritten.

Greetings, Martin

[Linux Fun]

Hi Wei,

You can also try:

mt -f /dev/st0 setblk 0

to use variable block size. See if it works.

If can not use L&TT, you can also erase a spare tape use command:

mt -f /dev/st0 erase

It might take long time to empty each bit on 125m tape. If it is done successfully, the drive can write properly, then you can try a small backup on that tape. If it's working, then the issue is "logical" not "physical".

[Michael Schulte zur Sur]

Hi,

this new tape isn't by any chance a DDS-4 tape?

greetings,

Michael

[Wei_10]

Again, thanks to all who responded.

I trid "mt -f /dev/st0 setblk 0", that did not change a thing. The same message about "Wrote only 0 of 10240 bytes".

And I am sure those tapes are not DDS-4 tapes, since some are used for a while. And the company bought all of them with the tape drive.

By the way, I got ltt installed. But it complained about not being able to find the "sg" device, although I can find /dev/sg0 fine. I tried to download the manuals from HP but have only been getting FTP server timeouts. :-(

Is there a way to tell ltt what device to use?

Thanks again.

[Martin P.J. Zinser]

Hello Wei,

I just went to

http://h18006.www1.hp.com/products/storageworks/ltt/documentation.html

and was able to get the documenation for ltt from there without problems.

Greetings, Martin

[Wei_10]

Thanks, Martin.

The manuals do not address my problem, actually.

Anyway, here is how far I've got with hp_ltt:

+- Informational: Raw Text -----------------------------------------+
| |
| OC_Exception_c caught: Internal error (oc_devicemap_linux.cpp, |
| 534, Unable to find the sg device file) |
| |
| |
+- Press any key to continue ---------------------------------------+

[Martin P.J. Zinser]

Hello Wei,

sg is the SCSI device file. Can you do a
cdrecord -scanbus (as root)? If yes, what is the result.

Greetings, Martin

[Wei_10]

# cdrecord -scanbus
Cdrecord-Clone 2.01a25 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J�rg Schilling
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.8'.
scsibus0:
0,0,0 0) *
0,1,0 1) *
0,2,0 2) *
0,3,0 3) 'HP ' 'C1537A ' 'L111' Removable Tape
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7)

[Martin P.J. Zinser]

Hello Wei,

this looks good, the tape is found on the SCSI bus and as you can see, so is the sg device. I do not know much about ltt, so hopefully somebody else can comment on the error you posted. Sorry I can not help better.

Greetings, Martin

[Wei_10]

It just hit me that I am running out of space in those tapes. I didn't think of it because the error occurs at a block number that is slightly different everyday. But I just realized that they are not that different: from 1491688 to 1495432. Which means that the tapes have a capacity of ~14GB.

Could it be that simple?

I put a "mt -f /dev/st0 compress on" in my backup to see if that helps.

I will report back tomorrow.

[Andreas Sundstrom]

I just got L&TT to work on a non RedHat system. My system is using devfs and what got things working for me was to create some device nodes.

mknod /dev/sga c 21 0
mknod /dev/sgb c 21 1
mknod /dev/sgc c 21 2
...

Just wanted to make this thread help someonelse who was searching for the L&TT error

[Ross Anderson_1]

I've been struggling with the configuration of the ltt utility on Gentoo w/ dev file system. I'm able to address the device using mtx at /dev/sg1 which is how gentoo has defined the device. The 4 dlt 7000 devices are also avail at /dev/st0 - /dev/st3.
When I start the llt utility is does not find any devices. I've tried suggestions posted here. Any thoughts/comments as to how I can get this utility to work under this distro? Kernel Version 2.4.26

[xyko_1]

Hi Wei,

if you are going out of space you may set tar to ask for a new tape when the first one has finished. I guess that the option is -M (multiple volumes).

regards,
xyko