I'm not sure that a dismantle will solve your problem, but your problem
sounds
similar to a couple situations we've had where it did resolve the problem.
Your SAN consultant is correct - it shouldn't be necessary!
The team I'm
on also handles our SAN, san storage - so we fight
strange happening with storage also. If we start getting
errors on a disk HBA (DISK OP errors, FCS errors, FSCSI errors)
one standard thing to try is to dismantle that path.
We remove the path, drop the hdisks, fscsi, fcs devices, and cfgmgr it all
back in.
Many times this clears the problem up.
We're convinced that deep within AIX bits can get out of sync
that can cause problems, where the solution is a complete
rebuild.
Your SAN consultant is correct - it shouldn't be necessary!
Rick
Fred Johanson
<Fred AT UCHICAGO DOT ED
U> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: TS3500 PROBLEM
06/06/2010 10:41
PM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
John, Rick, Wnda, Nick, et al.
Thanks for your input. In the past we've dismantled the whole tape system
whenever we've made a library or drive update. The SAN consultant who's
been hanging around all spring says not necessary, but it's on the schedule
for our next maintenance period on Wednesday. So is the powercycle
recommended by the CE SANDISCOVERY, the favored culprit of Support, is
turned off on all instances. Our next CritSit conference with IBM is
scheduled for Tuesday.
What I've seen since last Wednesday is 200 + failed tape mounts; dozens of
drive open errors on 4 of the 6 instances, not always the same drive; and
dozens of failed maintenance schedules, some of which have been restarted a
dozen times to get thru maintenance.
Support seems fixated on SANDISCOVERY, but the real problem certainly seems
to be the Reservation Conflict. Maybe they will come to that conclusion
before our conference. I still lean towards AIX andhardware. We'll know
more Tuesday.
I'll let you know what's happening.
________________________________________
From: ADSM: Dist Stor Manager [ADSM-L AT vm.marist DOT edu] On Behalf Of John D.
Schneider [john.schneider AT COMPUTERCOACHINGCOMMUNITY DOT COM]
Sent: Friday, June 04, 2010 4:05 PM
To: ADSM-L AT vm.marist DOT edu
Subject: Re: [ADSM-L] TS3500 PROBLEM
Richard,
"dyntrk" is set to "no" on our systems. I am not familiar with this
setting; what does this have to do with this problem?
And I have always been told that SANDISCOVERY should be NO on AIX.
Of course, things like that change, and I remember reading an APAR where
the default setting changed at some version of 5.5.
Best Regards,
John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424 / Toll Free: (866) 796-9226
Cell: (314) 750-8721
-------- Original Message --------
Subject: Re: [ADSM-L] TS3500 PROBLEM
From: Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM>
Date: Fri, June 04, 2010 3:20 pm
To: ADSM-L AT VM.MARIST DOT EDU
> mount. But if Library Client's tape paths are in error, and his path
> definition for DRIVE1 is actually pointing to the logical device for
> DRIVE2, and DRIVE2 is already in use by somebody else, he will get an
> error trying to open DRIVE2, and that will cause a Reservation Conflict.
>
> So it would be worth checking to make sure that all the paths on the
> LIbrary Clients point to the correct paths.
Also, make sure the s/n and wwn of the drive (q drive f=d) is
correct for the rmt/paths you define.
. . . but . . .
The couple times we had this kind of problem I
crawled through all the info for drives, paths, rmt. Everything
was correct for all tsm servers and storage agents.
But we still got mount failures and reservation
conflicts. That's why I finally deleted _everything_ and
recreated it all.
Do you have dyntrk set on for the fscsi protocol device (lsattr -El
fscsiX)?
We do. I've often wondered how it interacts with sandiscovery.
Rick
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
