Zoltan,

I haven't tried this on Linux.

But for a Windows or AIX TSM server you can add SANDISCOVERY ON in the
dsmserv.opt file.  You should also have the drives defined with AUTODETECT
YES.
(Check to see if it is working by entering:  Q SAN)

Then TSM SHOULD update the path/serial # automatically when there is a
change.

(FWIW, this isn't an LTO2 issue; can occur with any type drive.)



On Mon, Apr 21, 2008 at 9:19 AM, Zoltan Forray/AC/VCU <zforray AT vcu DOT edu>
wrote:

> I seem to always have issues when replacing LTO2 drives (3583-L72 library)
> that fail and would like to know what folks do out there, to handle it
> better than we do.
>
> I currently have two dead/failing LTO2 drives.
>
> When I pull one out and replace it with a spare, TSM wont use it and TSM
> complains about the serial # and not being able to find the correct drive.
>
> 4/19/2008 9:01:58 AM ANR8963E Unable to find path to match the serial
> number defined for drive LTO-DRIVE5 in library IBM3583-2 .
>
> In the past, I have had to shut down all TSM servers and bounce the
> lin_taped/IBMtaped process and/or bounce the server to rediscover the SAN
> attached devices and reassign the new serial numbered drive and remove the
> old one.   If there is a SAN path order shuffle and any drive gets a new
> /dev/IBMtapenn, I have to reconfigure the paths for every drive effected
> by the "musical chairs" reorg.
>
> Your suggestions on how to better handle this (besides just chucking these
> !@#$%^&*() LTO2 drives, which I hope to do within the next 1-2 years)!
>
> All servers are Linux  RH4. The library owning servers are 5.5 lin_tape
> drivers at at the latest level for the kernel (2.6.9.55 kernel - 1.10
> driver)
>