Well, I've gotten a little further along. The drives and paths have been added
to TSM and TSM is reporting all the information correctly (SN, Support RW
types, WWN's, etc.). Still haven't tried opening the drives and
reading/writing tapes (next step). The init script I use to load lin_tape is
as follows: (this is actually just a basic rc script that we have to use for
customized applications. lin_tape has its own /etc/init.d/lin_tape start up
script, but I have opted not to use it for now):
[ -x /etc/init.d/functions ] && . /etc/init.d/functions
echo -n "Starting lin_tape: "
modprobe lin_tape
RETVAL=$?
[ $RETVAL -eq 0 ] && [ -x /usr/bin/lin_taped ] && /usr/bin/lin_taped start
RETVAL=$RETVAL||$?
echo -n "Binding IBMtape and IBMchanger devices: "
[ $RETVAL -eq 0 ] && /sbin/udevtrigger
echo
Notice how udevtrigger is there. I don't believe that's in the lin_tape init
script by default. We've rebooted the server several times, have created new
kernel updates regularly and nothing has been able to break the lin_tape
functionality, so that's a plus (knock on wood). We're on a pretty recent
kernel though, so that must be helping some:
$ uname -r
2.6.18-194.11.4.el5
Lin_tape version
#modinfo lin_tape
filename: /lib/modules/2.6.18-194.11.4.el5/kernel/drivers/scsi/lin_tape.ko
version: 1.41.1
license: GPL
description: IBM Linux SCSI Tape Device Driver for IBM Tape Devices
author: IBM Corporation
srcversion: CA19B1A253F80F44D925789
depends: scsi_mod
vermagic: 2.6.18-194.3.1.el5 SMP mod_unload gcc-4.1
SF
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, October 08, 2010 12:19 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Looking for SAN/tape experts assistance
Sergio,
Thanks for the experience/guidance/details. Looks like we may be heading
in this direction, although we aren't sure why.
To update our situation.....
After doing some digging and pure-luck, I discovered one of the fibre
connections had gone "amber". Not sure why since when we cabled the
server to the switch, we always make sure it is green. Working with the
SAN person (tried cable swapping, etc), he discovered that switch port was
set to 1GB vs auto. He reconfigured to auto. I rebooted the server
5-times and after the 2nd reboot, the /dev/IBMtape values seemed to stay
the same after each reboot.
We thought everything was smooth sailing until last night (
http://www.wtvr.com/news/wtvr-downtown-smoke-power-grid-story,0,3680878.story
)
After we got things back up and running today, not only did the
/dev/IBMtape mappings change on this server, but it also changed on my
1-production 6.1 server, which in the past had been steady. The
4-production 5.5 servers did not change.
So, we are sortof back to square-1.
I am beginning to wonder if it has something to do with the OS. All of
the 5.5 servers are running RH4 or older RH5 kernels (-92 vs -128/-194)
Did you finish testing your configuration/accessing the drives?
I am curious - are other folks out there who run Linux TSM servers
creating these rules?
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT 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
From:
"Sergio O. Fuentes" <sfuentes AT UMD DOT EDU>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
09/27/2010 01:43 PM
Subject:
Re: [ADSM-L] Looking for SAN/tape experts assistance
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
I'm doing this work right now for a big project here. My first endeavor
into Linux.
The lin_tape drivers for 6.2 will require a .rules file in
/etc/udev/rules.d (or wherever your udev stuff lives) mainly because of
the instance owner/group requirements to run 6.2 dsmserv processes. Unless
you can alter your default udev rules for EVERYTHING, then you'll need the
.rule file to assign ownership and mode parameters for the tape devices.
Mine, so far, looks like this:
#cat /etc/udev/rules.d/98-lin_tape.rules
KERNEL=="IBMchanger*", SYSFS{primary_path}=="Primary",
SYSFS{serial_num}=="0000078150090402", OWNER="tsminst1", MODE="0600",
SYMLINK="lin_tape/IBMchanger137B"
KERNEL=="IBMchanger*", SYSFS{primary_path}=="Alternate",
SYSFS{serial_num}=="0000078150090402", OWNER="tsminst1", MODE="0600",
SYMLINK="lin_tape/IBMchanger138A"
KERNEL=="IBMtape*[0-9]", SYSFS{ww_port_name}=="0x5005076300549127",
OWNER="tsminst1", MODE="0600", SYMLINK="lin_tape/IBMtape137"
KERNEL=="IBMtape*[0-9]", SYSFS{ww_port_name}=="0x5005076300549128",
OWNER="tsminst1", MODE="0600", SYMLINK="lin_tape/IBMtape138"
KERNEL=="IBMtape*[0-9]", SYSFS{ww_port_name}=="0x5005076300549129",
OWNER="tsminst1", MODE="0600", SYMLINK="lin_tape/IBMtape139"
KERNEL=="IBMtape*n", OWNER="tsminst1", MODE="0600"
There are a lot of gotchas with this method that I'm running into. I'm
not sure if they are kernel bugs or driver issues but not much of this is
documented anywhere. Bullet-list (so far):
- If you have alternate pathing or data path failover, lin_taped needs
be installed and running. Problem is getting persistent binding to work
with this. There's a race condition where once modprobe lin_tape is run,
the udev files are created with the rules. But the SYSFS{primary_path}
key isn't defined correctly until lin_taped is run, BUT lin_taped can't
run until lin_tape is loaded. So by the time lin_taped is executed and
running, the lin_tape rules have already been processed for udev.
o My workaround will be to create an init script that will run
lin_taped and then udevtrigger. Seems to work, but udevtrigger once
crashed the system.
- Sometimes when lin_tape is loaded, the mode is incorrect for devices.
The fix is again "udevtrigger".
- KERNEL=="IBMtape*" doesn't work for renaming, because sometimes a
symlink to IBMtape1n is used instead of IBMtape1. Which is why I have the
character class "IBMtape*[0-9]"
Here's the output for ls /dev/ commands for when I believe things are
configured correctly. Caveat: I haven't even tested reading/writing to
these devices yet, let alone defining the devices to TSM.
#ls -l /dev/IBMtape*
crw-r--r-- 1 root root 250, 3071 Sep 27 11:43 /dev/IBMtape
crw------- 1 tsminst1 root 250, 0 Sep 27 11:43 /dev/IBMtape0
crw------- 1 tsminst1 root 250, 1024 Sep 27 11:43 /dev/IBMtape0n
crw------- 1 tsminst1 root 250, 1 Sep 27 11:43 /dev/IBMtape1
crw------- 1 tsminst1 root 250, 1025 Sep 27 11:43 /dev/IBMtape1n
crw------- 1 tsminst1 root 250, 2 Sep 27 11:43 /dev/IBMtape2
crw------- 1 tsminst1 root 250, 1026 Sep 27 11:43 /dev/IBMtape2n
#ls -l /dev/lin_tape
total 0
lrwxrwxrwx 1 root root 14 Sep 27 11:43 IBMchanger137B -> ../IBMchanger0
lrwxrwxrwx 1 root root 14 Sep 27 11:43 IBMchanger138A -> ../IBMchanger1
lrwxrwxrwx 1 root root 11 Sep 27 11:43 IBMtape137 -> ../IBMtape2
lrwxrwxrwx 1 root root 11 Sep 27 11:43 IBMtape138 -> ../IBMtape0
lrwxrwxrwx 1 root root 11 Sep 27 11:43 IBMtape139 -> ../IBMtape1
HTH,
Sergio
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Wednesday, September 22, 2010 2:53 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Looking for SAN/tape experts assistance
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
zforray AT vcu DOT 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
|
