retrospect crashes when accessing Magnum Tape Library

[montereyvideo]

Retrospect 6.1 crashes when accessing Exabyte Magnum 224 Tape Library

 

I recently installed an Exabyte Magnum 224 LTO3 Tape Library as my archive system. It is connected to my Mac via Fibre Channel. The System Profile recognizes and IDs the Drive and Library system.

 

When I start Retrospect and try to scan my devices, it gets to the point of checking the Fibre channel then just freezes.

 

Here’s a quick breakdown of my specs:

 

Power Mac G4 Dual 1 GHz Processor, 1GB RAM, OS 10.4.11

Exabyte Magnum 224 Tape Library – LTO3

Fibre Channel connection

 

Retrospect 6.1.230

Driver Update 6.1.16.100

 

Here is a compilation of screens shots if it helps.

 

 

What am I missing here?

 

Thanks.

 

 

[rhwalker]

That's odd. Looks like you are doing everything right. I will comment that you have an extremely small amount of RAM in your computer, especially for a DualProcessor machine, and especially for running Retrospect. I'd suggest at least 2 GB.

 

Have you tried the Exabyte ltotool to exercise the drive and run diagnostics? That would let you know if the drive can be manipulated independently of Retrospect, and the Exabyte libtool to exercise the autoloader? If you can't get ltotool and libtool to work, there's no hope for getting it to work with Retrospect.

 

Only other thing I could suggest is moving them to some other ID.

 

And I assume that you have updated the firmware in the Exabyte drive and autoloader, same question for the FibreChannel interface?

 

I will remark, just in case it helps you in your troubleshooting, that you are seeing the EXACT same behavior we saw with Retrospect 6.1 a few years back but on SCSI (not FibreChannel) and our Exabyte VXA-2 1x10 1u (SCSI) PacketLoader. In our situation, it wouldn't happen on every device scan, just about once every week or two, and was very hard to reproduce.

 

Our setup had the tape drive and autoloader on the same SCSI channel of our ATTO UL4D as a RAID 1 SCSI mirror of the system volume.

 

All of our problems disappeared when we put the tape drive and autoloader on their own SCSI channel of the UL4D, and the disk drive on the other, at the suggestion of Retrospect support. It's my suspicion, though never confirmed, that Retrospect was somehow causing the SCSI driver to do something during the device scan (such as a SCSI bus reset) that was making the disk drive drop a "transfer complete" interrupt. Because the disk drive also was used for the VM paging store, that caused all paging to stop, making it look like the CPU was hung. Attaching a monitor and keyboard (it was a headless server), we were able to see, the next time it happened, that the OS was still alive because keyboard and mouse activity still occurred, but the system was deadlocked because no paging I/O could occur.

 

But it doesn't appear that you have anything else on that FibreChannel interface, so yours may be a different issue.

 

Perhaps this will help you troubleshoot the issue.

 

Russ

Edited December 23, 2009 by Guest

[montereyvideo]

Thanks Russ -

 

At least I'm on the right path. I'll check your suggestions on Monday and get back to you.

 

 

[montereyvideo]

Hey Russ,

 

Well I moved the Library/Drive to a G5 system with 2GB RAM and everything works great now.

 

I do have one more question, if you don't mind that I mention it in this post...

 

When doing a large archive that spans across multiple tapes, I put enough blank media in the library, but Retrospect won't automatically take the next tape when the current one runs out.

 

I have to manually eject the current tape and manually select the next tape and drag it into the drive icon, then select Proceed.

 

These are fresh tapes that are shrink wrapped right off the shelf. Should I go through and erase them before use? Or is there some sort of automated setting inside retrospect.

 

I am moving from a VXA-2 7-Tape autoloader that does all the automation, so I know it works.

 

What do you think?

 

Thanks again.

 

Josh

 

[rhwalker]

Hey Russ,

 

Well I moved the Library/Drive to a G5 system with 2GB RAM and everything works great now.

Ok. It would be an interesting regression test to add more RAM to the original system and retest there.

 

I do have one more question, if you don't mind that I mention it in this post...

 

When doing a large archive that spans across multiple tapes, I put enough blank media in the library, but Retrospect won't automatically take the next tape when the current one runs out.

 

I have to manually eject the current tape and manually select the next tape and drag it into the drive icon, then select Proceed.

 

These are fresh tapes that are shrink wrapped right off the shelf. Should I go through and erase them before use? Or is there some sort of automated setting inside retrospect.

Works fine on our autoloader (see configuration above), so I'm a bit baffled here.

 

Check your preferences (Special > Preferences).

Does Retrospect see these new tapes as erased? If they are, it should use them. See page 43, top of the second column, of the Retrospect 6 Users Guide:

 

Tape Library Media Requests

 

During immediate and automated operations, Retrospect scans the library, searching for the appropriate media, and loads whichever tape is required. If a new or erased tape is required, Retrospect will load and use the first one available.

 

If it cannot find an appropriate tape to use, Retrospect displays the media request window. The operation cannot continue until you insert media.

I will go off on a rant here about a Retrospect 6 bug that I reported years back, related to the above paragraphs, but a bit unrelated to your request, that makes management of barcoded tapes almost impossible with Retrospect 6.

 

Basically, even if you have a barcoded tape that has been "erased" with Retrospect, such that Retrospect has named the tape and put down a Retrospect header on the tape, and Retrospect has made the barcode to tape member name association, if Retrospect needs an erased tape and is asking for an erased tape of a specific name, even if such a pre-erased pre-named barcoded tape exists in the autoloader, Retrospect will randomly choose from any erased tape in the autoloader, ignoring the fact that the correctly-named tape already exists.

 

This bug was fixed years ago in the Windows Retrospect version, but never in the Retrospect 6 Mac version.

 

Now that Retrospect 6 is dead, it will never be fixed. Whatever.

 

Check your preference settings. You should not be seeing the behavior that you are seeing.

 

Russ

[montereyvideo]

Hey Russ -

 

Thanks for the help. I'm pretty good at Retrospect 6, but I forget all the little details whenever I set up a fresh system.

 

I've adjusted the preferences and it should be good from here.