LUNs data changed

[gwp72]

We have a IBM FAStT900 connected to several Sun servers via a fibre channel switch. One of the sun servers (v240 running Solaris 2.9) reports the warning:-
ASC: 0x3f (reported LUNs data has changed), ASCQ: 0xe, FRU: 0x0
every time a LUN is created or deleted on the FAStT, but the other servers are ok. The server has a single QLA2340 HBA connection to the switch, has StorageManager9.1 and the switch zones separate each server.
Any ideas as to what could cause this?

Thanks,
G.

 

[fluffybunny]

Do check your hardware zoning setting for that server to see if it is isolated from the others or not.

 

[gwp72]

Zoning is configured so that the only other switch port the server has access to is the FAStT controller,
G.

 

[fluffybunny]

This is your management console, I assume ?
If it is, messages such as these will be sent to it.

Do a diagnostic run on your FastT to see if there are any problems.

 

[fnork]

You've probably already gotten the answer to this elsewhere.

What you're seeing should be no big deal. This is a normal behavior that is mandated by the SCSI spec. This SCSI unit attention is issued to the host to advise it of the changed logical unit condition. The host OS can (and should) use this as a hint to rescan the target to see if a LUN has been added or removed, or if a the logical unit (the real volume underlying the LUN number) associated with a LUN has changed. The host should retry the command that precipitated the unit attention, so you should see no effect at all on operations.

The unit attention is reported to all hosts affected by the LUN inventory change. So if you added (or removed) a LUN for this host through the storage manager, then you should see the UA for the next command that that host issues to the target. The UA is cleared for that host after it is reported, so you won't see another until you add/remove another LUN.

If you were presenting a LUN to multiple hosts (say, a LUN that you were using for a cluster), then the UA should be maintained independently for each host. That is, you should see exactly one of these messages on every host that you presented the LUN to.

I don't work for IBM, so I can't say whether they implemented this function exactly to the spec, but I hope this explains the behavior you're seeing.

 

[gwp72]

Hi,

Thanks for the info. That makes sense but not sure it completely answers the question.
What I'm still not sure about is why this host gets these messages whenever you create/delete a lun, ie. before it is assigned to ANY host. Its also a mystery as to why I dont see the message on other similar hosts...
As you say it is not causing a problem and now I know what the messages mean its not a worry but it would still be nice to know whats different with this host.

G.

 

[SirVictor]

We have the same problem using StorageTek FLA arrays, so this is not vendor specific, FAStT are basically the same arrays.

The Solaris SCSI write error is a response to a SCSI check condition issued by the arrays, this condition is "Reported Luns Data has Changed". Which makes sense, as you are creating/deleting LUNs. You will probably also get the same message when mapping LUNs.

We are meeting with StorageTek/SUN/Qlogic next week to see how this can be resolved once & for all. We have been battling this for nearly a year now.

 

[gwp72]

Thanks for the post... please let us know if they come up with the solution!
G.