> What I did onto Netapp server is
> 1) Offline the the LUN
> 2) Unmap it
> Maybe I did it on the other way around but the result was that!!
Ok, That explains the problem. Since you are performing no
actions via the Solaris host the only want the Solaris host is going
to know if the LUN is offline/unmapped is if the target tells
it. My prediction is its not since solaris thinks the LUNs are still
online and mapped.
The NetApp case also gets a little more confusing, based on
memory. With NetApp they actually let the initiator connect to
the target even if no LUNs are mapped. You would end up with
a "iscsiadm list target -S" result similar to the below in this
case, with no LUNs listed. (Again this is based on memory.)
[EMAIL PROTECTED] # iscsiadm list target -S
Target: iqn.1992-08.com.netapp:sn.135031143
Alias: -
TPGT: 2000
ISID: 4000002a0000
Connections: 1
In your case you still have LUNs listed. What would be recommended
by the target is it send the initiator an "Asynchronous Message" to
notify the initiator of the change. (If your familiar with FC this would
be like a LIP or RSCN.) Without this "Async Message" or at least a
hard connection disconnect the initiator doesn't know anything changed.
A "Async Message" or disconnect would cause the host to rescan the
LUNs and discover your LUNs are gone.
A possible workaround might be to issue "devfsadm -C". This will force
the initiator to rescan the target's LUNs and the code used to remove
the LUNs. (There is one assumption here though. "devfsadm -C" will
not remove the LUNs if they are in use (ie. mounted/open/etc). Also
one more point about devfsadm. If you don't use the -C operation the
initiator will still discover the LUNs are gone but the Solaris IO subsystem
will not clean up the /dev links. So I recommend using the -C option.)
Not to pick on NetApp because they really have a great product! But,
Just for comparison purposes. Many other vendors expose a one iSCSI
target per LUN. NetApp exposes one target (per node) with multiple
LUNs. The advantage of the one LUN per target is the target can disconnect
(offline) the LUN without effecting traffic to any other LUNs. Its my
assumption this is the major reason NetApp doesn't send a "Async
Message" when a LUN is offlined. It would effect all LUNs on the
target, in most cases. In addition one LUN per target allows a iSCSI
target to better load spread IO across LUNs. (Again I'm not picking
on NetApp they have a great product. There design has pros and cons.
As a customer you just need to understand your targets pros and cons.)
Hope this helps. Again a possible workaround might be issuing "devfsadm -C"
after the LUN is offlined/unmapped on the target. If you want to understand
the async messages better in iSCSI consult the following URL and search for
"Asynchronous Message", http://www.ietf.org/rfc/rfc3720.txt?number=3720
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
