HP C5683A Surestore DAT40, backup to DDS-2 works, DDS-4 gives I/O error

[evdsanden]

Hi,

I'm trying, using a HP C5683A Surestore DAT40 to create backups on new media of type DDS-4 using commandline utility mt and tar. When I try to tar to the drive it fail with and write fail, I/O error. When I try to erase the tape it shows me a fatal error. When I perform both steps on a DDS-2 tape all is OK. I also ran the ltt utility on the drive, this shows a similar issue, DDS-2 succeeds, DDS-4 fails.

Do I need to write settings to the drive or add options to the utilities to be able to use DDS-4 tapes?

My configuration is an Adaptec 2940U2W controller connected to the HP C5683A Surestore DAT40 on a CentOS 5.3 linux system.

[Fabio Ettore]

Hi,

it seems to me an HW issue of DDS-4, no operating system problem. Have you checked that aspect?

Best regards,
Fabio

[evdsanden]

I ran a test from the bacula suite named btape, which runs successfully on the DDS-2 tape, but fails on the DDS-4. I also tried to run ltt, which showed a write failure only on the DDS-4 tape. I just read somewhere about the difference in thickness of tape for DDS-2 and DDS-4. Figuring that, I think I could have troubles taped feeding as a results of a dirty drive, although I used a cleaning tape on a regular basis.

[Hakki Aydin Ucar]

Hi,

Apparently you have a bottleneck with Media and System:

Is it first time to backup with DDS-4 ?
if so,
-check and be sure somehow your SCSI bus supports it ?
-And besides, maybe problem is media DDS-4 Tape itself ? did you change and try with new one ?

[evdsanden]

@Hakki

I use an adaptec 2940U2W scsi adapter which supports 2 scsi 68pin connections, on is for ultra2 and the other is wide ultra. The drive is connected to the wide ultra interface, which is, I believe the interface that is used by the drive and I use a cable that is terminated at the drives end. The system, by the way, is a P4 2.4GHz PC with 2GB memory. I figured that if backups succeed on DDS-2, DDS-4 should work too ?

PS. This is the first time I'm running a backup using DDS-4 tapes. I tried several all new ones. My old DDS-2 tapes, run flawlessly.

[Hakki Aydin Ucar]

I used to play with Centos it is free of charge Enterprise Linux, and it was compatible most HW as far as remember.
I checked internet , I do not remember where I met this article but:
->>
since mixing fast Ultra2 SCSI devices with slower Ultra SCSI ones would cause problems, usually resulting in all bus traffic running at the speed of the slowest device.
->>
did you try backup with ultra wide scsi connected to DAT40 while all scsi slots empty
to get rid of above problem ?
And did you try another brand of DDS-4 media?

[evdsanden]

The tapedrive is the only device connected on the scsi bus and I have to different brands of tapes, both fail. Yesterday I connected another DDS-4 capable tapedrive (DELL), this tapedrive gives me the same result, I can backup to DDS-2 but not DDS-4. I checked specs of both drives, both are capable of handling DDS-4, I cannot understand the issues I got with these drives?

[evdsanden]

Additional I notice that the errors always appear at the same block, regardless which DDS4 tape I load. It looks to me as if the drive can not handle DDS4 tapes due to a configuration issue? I figure that if I have scsi interface problems the errors should be more random.

[Marino Meloni_1 · Accepted solution]

You wrote LTT reported a write error during the test.
Can you run again the test and after the failure, with still the tape inside the drive, collect a support ticket and attach it here?

[evdsanden]

Hi Marino,

Here's the report I get from the hp_ltt utility program. I did perform a clean drive 5 times in a row as inidcated without any success, it still reports that I need to clean the drive ? I cannot figure why it won't use my DDS-4 type tapes. I have tried both Sony and Imation tapes new and old.

[Marino Meloni_1]

I had a look at the ticket,
most of the errors are related to the tape or to the drive head, not sure if these errors are caused by the tape itself or by the drive.
I would like you run the assesment test using a known good tape (new one is best) and at the end the test should give the answer if the drive is good or not.
Related to the use of DDS2 tapes for a long time on new drives, this can cause some kind of profiling on the read/write head, causing the drive to be unable to use higher density tapes.
There was in the past a recalibration script available, but using it may cause the drive to not be able to use the DDS2 drive anympre in addition to not use the DDS4.
The only strange thing from your thread is that you report that using another DDS4 drive you get the same issue, did you try to attach them to another HBA with different OS and see how it run? every communication goes through drivers, so a old or wrong drive can cause potentially communication issues, and this can cause unpredictible results

[evdsanden]

Hi Marino,

I repeated the test with a complete new tape and that test went OK. The previous "new" tapes I used, I tried to use them previously on an other DDS4 tape drive, looks like that drive ruined my tapes or is there a way to reformat the tapes so they can be used with this tapedrive ?

[Marino Meloni_1]

If you cannot use them with LTT, i doubd you can reformat them.
Depending how they are damaged, you may try to degaus them and see if you can reuse again

[Richard Thomson_1]

I was Senior German Engineer for Tech-Support at Veritas Enterprise Tech-Support and I used to deal with at least 20 of these calls per week.

The main reason for the I/O error is that the tape drive has probably been configured for SCSI ID six (6). There is a known issue with configuring it to this ID and the source can be found in the c't Magazine, vol 18 from 1998 page 193.

If you reconfigure your drive to SCSI ID five (5) then that will sort it.

The problem relates to the introduction of SCAM - "SCSI Configured AutoMagically" by Adaptec.

Also if your 2940U2W is an onboard solution then that would account for the SCSI sense ID 9 and 11 errors you are getting.

[Marino Meloni_1]

Hi Richard
reading the support ticket attached to the thread:

Tape Drive at address (0.5.0[0-/dev/sg0])

that was ok, aslo because if you have a scsi id conflict you cannot see the device at all

Regards

Marino

[Richard Thomson_1]

QUOTE
aslo because if you have a scsi id conflict you cannot see the device at all
UNQUOTE

My post did not in any way shape or form refer to a SCSI ID conflict.

Even in the case of an apparent "SCSI ID conflict" then one might be dealing with something like a Surestore DAT 40*6 which has two SCSI devices on the same ID but on separate LUNs.

Here is the Technote I personally wrote because I got sick of customers telling me that HP engineers were on-site and that the other number could NOT be seven because that was what the SCSI adapter is on - read the acknowledgement:

http://seer.entsupport.symantec.com/docs/231508.htm

Now it would be nice if you could share the ticket so that I could resolve the problem as I did back then, because I can guarantee it will take me longer to write the solution than to think about it.