If memory serves me issuing a devfsadm -C should have removed the unmapped
nodes, with two requirements. One you didn't still have the LUNs mounted or in
use on the host side. And two the target actually removed the the LUNs from
its SCSI report LUNs response.
The code path that devfsadm -C should follow is something like the below...
iscsi_tran_bus_config()
iscsid_config_all()
iscsid_login_tgt()
iscsi_sess_online()
iscsi_sess_state_machine(N1)
iscsi_sess_state_logged_in(N1)
iscsi_sess_enumeration()
iscsi_sess_reportluns()
iscsi_lun_offline()
Its down in iscsi_sess_reportluns() where this gets interesting. In this code
it should identify the LUNs have been removed. This code still without looking
closely looks correct. The identified luns are then offlined and I thought
removed if not in use. Although looking at the code now I don't see any
attempt to remove the LUNs. So maybe my memory is rusty. There is an
individual that knew this area of the code better than me. I will see if I can
still contact him as he also is not at Sun either any more. Unfortunately,
Sun's Network Storage source consolidation doesn't post there revision history
like the core consolidation so its impossible for an outside to see if there
was a regression.
The reason your disabling /enabling discovery is working is because if goes
thru
iscsi_sess_destroy() / iscsi_lun_destroy() which will remove the LUNs
structures in the driver. Disabling removes them all and when you re-enable it
just add the current ones back. I can't think of anything specific that would
be causing a problem on your other host though. Maybe on the disable the
detach of the sd driver is sending a target reset out. That could impact the
other initiators although I wouldn't expect a minute or two delay. There is
nothing specific in the iSCSI initiator that would be causing that issue. I
suspect its a target driver detach issuing a reset. Maybe someone else could
confirm that?
(This was just a really really fast examination of the current code.)
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
