ADSM-L

Re: [ADSM-L] Mixing LTO2 LTO4 in 3584 libr

2007-11-13 02:05:50
Subject: Re: [ADSM-L] Mixing LTO2 LTO4 in 3584 libr
From: Michael Green <mishagreen AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 13 Nov 2007 08:57:54 +0200
I was wondering whether such a setup is workable.

I'll describe my problem.

We have upgraded recently from LTO2 to LTO4. Right after the upgrade I
stumbled upon a problem that reading of LTO2 volumes was not reliable.
I was getting lots of errors in the actlog and eventually a process
would fail and the drive in question would be marked unavailable and
stay offline until I intervene.

Since IBM support could not quickly identify the problem and I was
under pressure to provide reliable restores I decided to replace one
of LTO4 drives with an old LTO2 drive which was still laying around.
After having the drive replaced I went ahead and performed the
nessecary 'del path', 'del drive'  followed by 'def drive' and 'def
path' in order to get this old-new drive working. I've tested the
setup right away and the library manager could read the LTO2 tapes
satisfactorily. However, soon thereafter I found that another TSM
server that acts as a library client had a problem accessing ALL of
the 8 drives in the same virtual library. It was filling the actlog
with ANR8447E errors and the Libr manager wouldn't allow the client to
access the libr. After trying this and that I found out that only
deleting BOTH the PATH and the DRIVE from the libr manager would
eliminate the problem. But of course not having the path and drive
definitions, and as a result inability to access this LTO2 drive
defeats the whole purpose of having it in the Library in the first
place!
As soon as I redefine the drive and the path the Libr client looses
access to the library again.  This behavior is consistent. Remove the
paths and the drive - get it working again!

Eventually I removed the LTO2 drive and inserted the LTO4 drive back
into the library. Ran del path, del drive, def drive, def path and
everything was back to where it were before the initial replacement.

Two or three days later IBM called and suggested that I upgrade the
microcode on LTO4 drives to the newest version that has just been out
- 77BB. It helped and while I still get more READ errors from my
legacy LTO2 tapes than I would normally expect, the situation is at
least tolerable now because the processes/session don't bug out and
the drives don't render themselves "Unavailable".

I would appreciate any thoughts/comments.

BTW, my servers setups are:

libr manager: RHEL 4U5, lin_tape-1.10, TSM 5.3.6.
libr client:    SLES9 SP3, lin_tape-1.10, TSM 5.3.6

On Nov 12, 2007 4:58 PM, Ribeiro, Ricardo <Ricardo.Ribeiro AT schwab DOT com> 
wrote:
> Yes... Do you have a specific question about the mix?
>
>




--
Warm regards,
Michael Green