There is a "by-id" section in the IBM Tape device driver installation and user guide (for LTO). Looks like it hooks into the RHEL udev stuff.
I would personally try to find the same guide for TS1120 and send you a link, but I'm fighting an EDL problem at the moment. Thanks, [RC] On Sep 22, 2010, at 11:53 AM, Zoltan Forray/AC/VCU <zfor...@vcu.edu> wrote:
I have mentioned in previous posts that we are putting up 2-new RH Linux based TSM server . These are the first of my existing 5-Linux servers to use EMC SAN storage. With every new adventure, we get new problems. This one is driving everyone crazy and hope someone out there can point us in the right direction. We have seen posts in ADSM-L that sorta talk about it, but nothing that explains what is going on with us or how to resolve it. Both new servers have been configured identically when it comes to the OS (RedHat Linux 5.5 kernel 2.6.18-194.11.3.el5) software and other hardware supporting software (EMC Powerpath and IBM lin_tape drivers - 1.41.1 for the TS1120/1130 drives) The problem is this. Every time we reboot one of the new servers, the values in /proc/scsi/IBMtape is different in the assignment of /dev numbers to the drives. It seems to find the tape drives in a different order each time. None of my 5-production nor the other new TSM server have this problem (I have rebooted the 2nd new server 4-times and the /dev/IBMtape? values stay the same). When looking through the "fixlist" for lin_tape (usually engineering-speak), we saw this interesting entry at the 1.37 level: Removed persistent naming script in favor of new method Questions come to mind about things like "what naming script"......."what new method" .... "could this possibly be related to what we are experiencing"? We have spent all day trying to figure this wrinkle out. Any suggestions are greatly appreciated. Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html