Jump to content

Dell PowerVault 122T autoloader


Recommended Posts

Is anyone successfully using the Dell 122T autoloader with Retrospect 5.1 for Mac OS X?

 

 

 

I purchased one two months ago after making sure that is completely certified for compatibility by Dantz for Retrospect. I am running it on an Xserve (also certified, with the stock factory SCSI card, also certified).

 

 

 

Unfortunately, I cannot get it to *reliably* work. It might work once, then it locks my Xserve up. It always results in a 100% CPU 1 utilization condition, with a totally unresponsive GUI. After about 3 minutes, the Xserve usually reboots itself, although sometimes it just hangs. I often come in early in the morning and find that the Xserve has rebooted itself during the night after Retrospect crashes it. I have had to rebuild corrupted catalog files so many times that if I could see one I would kick it.

 

 

 

Today was the last straw. I came in and the server was hung on the retroconfig file in Library/Preferences/Retrospect. After forcing a reboot, Retrospect would no longer start, complaining that its config file was hosed. Having to reenter the registration information was just a minor inconvenience. But having to add every network client and subvolume back in by hand really made my morning. Why is all of that important info stored in one big (obviously susceptible) file?

 

 

 

I have finally had to resort to removing the autoloader and do backups to an attached RAID cabinet (wasting 400 GB of not cheap RAID space.)

 

 

 

So, is anyone actually using this device with an Xserve and OS X and Retrospect 5.1? (It crashed under 5.0 also, thought that the upgrade might fix the problem. More money thrown at it...)

 

 

 

Dantz--Did you really bother to test the loader before certifying it?

 

 

Link to comment
Share on other sites

Here is more info on my setup. When I do backups from the network to the RAID (twice weekly now) it works perfectly. When I backup the RAID to the autoloader (once weekly) it almost always reboots the Xserve. I have tried swapping the devices to the opposite SCSI adapters and there was no improvement. The behavior is consistent across adapters.

 

Xserve Dual 1.33

Mac OS X Server 10.2.7

Retrospect Server v. 5.1.167, Drivers v. 4.0.103

 

First ATTO card: ExpressPCI UL3S-66 flash 1.6.6f0, driver 1.0.1f3, ATTO driver in System/Library/Extensions 2.0.4, located in SLOT C, used for a Storcase RAID, U160 auto negotiated

 

Second ATTO card:ExpressPCI UL3S flash 1.6.6f0, driver 1.0.1f3, ATTO driver in System/Library/Extensions 2.0.4, located in SLOT B, set to 80 (Ultra 2) in NVRAM on card, used for Dell autoloader

 

Dell PowerVault 122T, Product rev. E32k D37r, Firmware rev. 006337, 0370, 0340

 

I truly appreciate any help. I have an expensive paperweight right now, and no budget to buy a different certified autoloader.

Link to comment
Share on other sites

Hi

 

Do backups run if you try to backup non-SCSI disks to the autoloader?

Make sure you have installed the 5.1 SCSI updater:

http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28064

 

My hunch is that the SCSI bus to SCSI bus transfer of data may be causing the problem.

 

Dantz doesn't recommend this but...

You could try daisy chaining the loader off of the RAID device. I would only try this if you can sucessfully backup a non-scsi disk.

 

Thanks

Nate

Link to comment
Share on other sites

This is a good idea. I don't think that (in all my many permutations of reconfiguring and testing) I have tried backing up data to the tape drive from just the network clients, without including the RAID. If it works, then I will repeat including some of the server's IDE drives to see what happens with non-SCSI local backups.

 

I have mixed feelings about this, since the main job of the autoloader is to back up the RAID.

 

I will let you know what happens.

Link to comment
Share on other sites

The tape drive hangs when it is backing up either IDE or SCSI drives on the local host. It doesn't hang when it is backing up network clients.

 

It sounds like the tape drive is possibly being overrun with data by the fast local drives. I have gone into the NVRAM on the SCSI host adapter and locked the speed to 80MB/s, but it hasn't helped.

 

Any ideas? I can't help wondering again how Dantz was able to get it to work for certification when I have been completely unable to do the same. Perhaps I should try locking the speed to 40 or 20 MB/s.

 

As an aside, does anyone have any experience with non-ATTO SCSI adapters in an Xserve? If it remains unusable, I think that another host adapter may be the next step to try.

 

Thanks!

Link to comment
Share on other sites

Hi

 

I don't mean to point fingers here but I think there has to be something wrong with I/O on this machine- I would agree that it is a buffering or overflow problem. If it works for client backups there is no reason for it to fail other than hardware. Retrospect's driver works the same no matter what you are backing up.

 

Where are you saving the catalogs for your backup sets? If you havent't already try saving them on the RAID or on a network share. Anything to simplify I/O on the machine.

 

Was daisy chaining the devices a possibility? The nice thing about SCSI is it is smart enough to handle the data transfer between devices on the same bus without any help from the CPU. Having both devices on the same adapter could significantly reduce the load on your PCI bus (PCI is where I think the problem is).

 

I would try slowing down the I/O on the adapter too.

 

Thanks

Nate

 

 

Link to comment
Share on other sites

I am saving the catalog files to the RAID already, so I can't get any relief there.

 

 

 

It is a strange deal, because when I am saving to the RAID I get great throughput (around 1GB/minute) from the local IDE drives. No I/O problems at all. So, I suppose that this is a "can't slow down" problem on the bus, not a "can't pass the data" problem. Either that, or it is a tape drive/adapter/OS problem.

 

 

 

I have decided that the best thing to do is replace the two SCSI cards with one card to help reduce strain on the bus, and to probably change brands while I am at it.

 

 

 

I think that changing to Adaptec may be a good idea because 1) the server crashed when doing backups straight from IDE to the tape library, and adding a different ATTO adapter isn't going to change any variables there, and 2) it crashed when I daisy chained the two devices off of one controller, which should have cut the bus out of the picture.

 

 

 

The Dell loader shipped with an Adaptec controller (not one that will work in a Mac though). I am going to purchase an Adaptec PowerDomain dual channel controller. This will only have one SCSI adapter in the system, not two, and it will use totally different drivers. Hopefully all of this change will solve not create problems! I don't think that Adaptec provides the same level of support overall for the mac platform as ATTO (Apple's OEM choice), but I don't really have a choice at this point.

 

 

 

Thanks for the help! I will post back after replacing the host adapter.

 

 

 

Heath

Link to comment
Share on other sites

This is very interesting.

 

 

 

I can now recreate the entire situation including complete failure and reboot. It is completely predictable and I will be very suprised if it is a hardware problem.

 

 

 

The problem is with a specific file (type of file?) stored on the drive being backed up. I haven't seen the problem when backing up across the network because the file is only on the server itself. When I move it off of the RAID, the RAID backs up to tape perfectly. When the file is not on an IDE drive, the IDE drive backs up perfectly also.

 

 

 

In addition, the file only causes the hang/reboot situation when it is *locked*--when it is marked as locked thorugh its properties dialogue in the OS.

 

 

 

The file is a .dmg file. It is 2.6 GB in size, and it has to remain locked because it is a NetBoot image use for a computer lab.

 

 

 

I have verified these results in these ways.

 

 

 

1. I copied to the .dmg file to a spare IDE drive and tried to back it up. The machine froze. I then unlocked the file and renamed it. The backup worked perfectly.

 

 

 

2. I copied the .dmg file to the RAID. I locked the file. The backup failed and the server rebooted itself. When I got back into the system, the catalog file was so corrupted that Retrospect would not recognize it anymore. I erased and made a new catalog file, then I unlocked the file and tried again. It backed up perfectly.

 

 

 

I am not going to test across the network because the file is really too big.

 

 

 

I didn't notice this before because the file is usually the largest on the drive, so it is backed up first, so the backup immediately starts to go wrong. I only noticed it when I copied up a movie file that is larger and was backed up first. It worked perfectly until it hit the locked .dmg file.

 

 

 

This seems to be a retrospect error. I don't know why I can backup the locked .dmg file to the RAID and not the tape. Still, this error is so recreatable that I think it has to be something wrong in Retrospect, maybe with the way it handles the file specifically when it is locked and going to tape.

 

 

 

What do you think?? I am glad to be able to point at the problem at least.

 

 

 

Heath

Link to comment
Share on other sites

Hi

 

This is very interesting.

 

The biggest difference in the way the data is handled when going to tape is that the tape drive itself is doing the compression. When you backup to the RAID, Retrospect does the compression in software.

 

Is the image mounted when it is being backed up? Can you recreate this with another (smaller) locked .dmg file?

 

Try this:

Create a new tape backup set but turn off hardware compression at the backup set naming screen. This is the only opportunity you will have to turn off hardware compression. Then do a backup to that set using the software compression listed under "options".

 

If this backup succeeds we know it has something to do with hardware compression of the locked file. I will be completely stumped if this is really the source of the problem. If so we will need to follow this up at Dantz.

 

To work around this, set up a selector that excludes that file from your backup. Lets keep an eye on this to make sure that is really what is wrong.

 

Thanks

Nate

 

 

Link to comment
Share on other sites

Well, blow that theory all to hell. I was still able to recreate the effect with that file several times today, but changing the name of the file made it work. Then, I couldn't make it fail again. Also, network backups started getting choppy today to the Tape drive. CPU Usage frequently pegged out at full and the GUI locked up (SSH sessions from another computer become unresponsive also). Too many variables. The only constant is that the problems are all associated with the tape drive. Backups to RAID still go very smoothly.

 

I did create a set with hardware compression disabled today and tested using it, but I couldn't tell any difference. All of the behaviors seemed the same as with hardware compression enabled.

 

I am going to stop driving myself crazy with this and go ahead with the plan to replace some hardware. I will pick back up after that.

 

Thanks for your help with this. I do appreciate the suggestions.

 

Heath

Link to comment
Share on other sites

Hi

 

It sounds like the backup is failing in a more predicatable way now. File names and network/local sources should not make a difference if it is a device communication problem.

 

If possible I would try putting this same SCSI card and tape drive combination on another machine. That will really narrow things down.

 

To be honest I have reservations about Adaptec cards in OSX - some people have luck, others do not. If you are going to go that route try to buy it from a reseller who will allow you to return it if needed.

 

Thanks

Nate

Link to comment
Share on other sites

  • 2 weeks later...

The problem proved to be with the second ATTO SCSI card I had installed. I have replaced the card and everything is working very well now.

 

The problem configuration was this:

Xserve

ATTO UL3S-66

ATTO UL3S-33

 

When I had the two cards in together it was totally unreliable. I have since swapped the second ATTO card (-33) for an old ATTO UL2S and things work great. I will add in an Adaptec 39160 and remove the two ATTO cards soon.

 

Hope this is helpful for anyone having problems with this configuration. Thanks for the troubleshooting info!

 

Heath

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...