fn 2 rn 0 read error I/O error

[teaboy]

I am in an odd situation of trying to recover data from networker tapes created at another site by a portion of my company that no longer exists. Upon running scanner to find the contents of the tapes, I receive the following:

scanner: scanning dlt tape <tape #> on /dev/rmt/1cbn
scanner: fn 2 rn 0 read error I/O error
scanner: fn 2 rn 0 read error I/O error
scanner: done with dlt tape <tape #>

Where <tape #> is the volume in the tape drive. I have 29 such tapes, and although I haven't tried each and every one of them, I have tried several and received the EXACT error message.
I have verified that the networker version (5.1) is the same, that the tape is indeed a 35/70 that the operating system is the same, etc. Everything looks like it should work, but it doesn't. Here are the specifics:

OS: Solaris 2.5.1
Networker: 5.1
Drive: Quantum DLT7000

Any ideas would be greatly appreciated, I'm at a bit of a loss. I am able to run scanner on my own tapes with no problems, which I did for a sanity check.

Thank You

Tad

 

[Sunboxez]

Tad,

I had the exact same error msg as you last week. We found that the st.conf file had the wrong type of drive uncommented so scanner was trying to read the tape using another manufacturers drive settings. So the question I have for you is what drives where the old tapes written from? DLT4000 or DLT7000? If the old site used DLT4K drives and chose to use DLT IV media 35/70, you might be able to get away with editing your st.conf and uncommenting the DLT4000 entry. This is risky because you'll be sending 4000 commands to 7000 drives. If this drive doesn't participate in a library there might be a jumper setting to have the drive emulate DLT4K long enough to get the tapes restored. I guess it depends on how bad you need the data off the tapes. Your tapes run the scanner command no problem probably because your st.conf reflects your drives properly.

Hope this helps,

Larry

P.S. Don't wait for a DR/Migration of Legato to find out that your scanner command can't read tapes....really sux!

 

[teaboy]

Larry -

Thanks for the suggestion. I'm about 99% sure these came from a DLT7000 drive. It was a Storagetek 9710 which I doubt had 4000 drives although it DOES support that configuration. I'm trying to get verification (I never personally used the drives, and they aren't available to be looked at any longer). However, I've tried these tapes in both a DLT7000 and DLT4000 drive (we have both onsite) with no luck. However, I'd like to see if your st.conf settings are similar on the 4000 to the ones that I'm using. Here are the settings for the 4000:
tape-config-list = &quot;Quantum DLT4000&quot;, &quot;Quantum DLT 4000&quot;, &quot;QDLT4K&quot;;
QDLT4K =1,0x36,0,0x8219,4,0x17,0x18,0x82,0x83,3;

I've looked around at various places, and these seem pretty standard. For the record, the settings for the DLT7000 came right off of legato's site, as my current configuration didn't have a specific definition in st.conf:

tape-config-list= &quot;QUANTUM DLT7&quot;, &quot;Quantum DLT 7000&quot;, &quot;DLT7000&quot;;


DLT7000 = 1,0x36,0,0x8639,4,0x82,0x83,0x84,0x85,3;

My quest continues......

Thanks again,

Tad

P.S. In response to your P.S., the data I'm trying to get off these tapes was never supposed to be used by my division of business, therefore I didn't know they existed! Arrrggghhhh!

 

[1234qaz]

you may try it:
nsrjb -EH

 

[TDun]

Check that both servers are using the same blocksize. Otherwise you would get similar problems.

 

[keefb]

Seen this before, last time was a block size issue.

Check to see what block size the tapes were written at.

This obviously may be a problem due to the original server being out of commission. Regards
KeefB

 

[ooodeano]

This is definitely a blocksize error. I had the exact same problem with tapes that were written using fibre attached drives not able to be read with scsi attached drives. Fibre attached wrote at 128k blocksize and the scsi card was only capable of 64k.