Problems with Super DLT verifications

[jgarmer]

Legato is telling me this is bad tapes. How high does the pile of tapes have to get before you can call Quantum. Is anyone else seeing this problem on Solaris 2.6 networker 6.11 drive connect via emulex san connection through a modular Data Router. Backup was of a SAN STorage Node

08/02/02 01:02:12 nsrd: media notice: Volume "DC0341" on device "rd=orca1:/dev/ntape/tape14_d1": Cannot decode block. Verify the device configuration. Tape posi
tioning by record is disabled.
08/02/02 01:02:12 nsrd: media warning: verification of volume "DC0341", volid 12
41962241 failed, can not read record 4832 of file 37 on dlt tape DC0341
08/02/02 01:02:12 nsrd: media notice: verification of volume "DC0341", volid 124
1962241 failed, volume is being marked as full.
08/02/02 01:02:12 nsrd: media notice: Save set (1241974021) orca1:/clone/GABSAN_
dmn/vol09 volume DC0341 on rd=orca1:/dev/ntape/tape14_d1 is being terminated bec
ause: Media verification failed

 

[fraxx]

You could very well have a problem on the SAN. I had a problem with Legato marking tapes full prematurely, and it turned out the be the HBA in the backup server generating errors. After I replaced it, things went smooth. Legato is real picky about the data path.
/charles

 

[jdale2000]

I had the same problem.... with 20 SDLT's .. First of all make sure you are up to code 46 on your SDLT's (dlts are 220's)

I have seen about 18-20% bad tape and am now looking for a way to test some tapes without running 'tape' which takes days to run... I also have a lot of cleanings needed by the SDLT compaired to DLT7000's..

As of now - - The drive update to code 46 seemed to help the most.....

Hopes this helps....
John

 

[rogercase]

Ive been running 6.2 and thinking it was legato and have been going thru tapes like water as well. So its the firmware on the SDLTs??? Ive checked and checked cables tons of times on everything. What version are you running on legato with the updated firmware?

 

[jgarmer]

We're on 6.11 on Solaris running 4.6 of the firmware now like John seemed to happen a lot more on the previous version.Still happensnot as often. BTW, The tapes are not really bad turns out if you relabel them you may get a full load on them. I think there is still a problem in the firmware I wonder if it may be in the compression algorythm. I don't have the ability to turn it off to troubleshoot the problem for quantum. My guess is it will get fixed when enough units keep getting return for refurb.

joe

 

[rogercase]

I assume marking tapes that are full back to appendable wont do it????

 

[jgarmer]

didn't try it sounds possible tape may be missing eot though.

joe

 

[rogercase]

Ok well here is a new one for you, I can backup all day long but as soon as I need to label a tape. BAM all tapes go to the fsf error and need new tapes as if the capacity is reached on them. Any ideas?

 

[RMinNJ]

rogercase,

The tape label is written with a 32K block size? Perhaps
this confuses it.

We're having good luck with the SDLT's with Solaris 8;
except, we seem to get read errors now and then. Some
turned out to be bad drives laying down a "bad calibration
track". More often though, it appears to be bad media..
I concur, a disturbingly high percentage.

rmaiello

 

[rogercase]

how do I change the block size on Win2k for SDLT then?

 

[fraxx]

That's an environment variable in Windows.
NSR_DEV_BLOCK_SIZE_SDLT=<your wanted blocksize, typically 64 or 128>

/charles