OpenSolaris

You are not signed in. Sign in or register.

Installation

  • Install SUNWstmf and SUNWiscsitr
  • Reboot (shouldn't really need to but just to be safe)
  • After installing iscsit there will be no iSCSI targets defined. For the FCS release an iSCSI target will be automatically created after a fresh install but this not in place yet. To create a target:
itadm create-target

To look at the new target:

# itadm list-target
1 Target(s) found


Target: iqn.1986-03.com.sun:02:80c3a500-ff15-e656-aee3-bc63d49b449d
# stmfadm list-target
Target: iqn.1986-03.com.sun:02:80c3a500-ff15-e656-aee3-bc63d49b449d
    Operational Status: Online
    Provider Name     : iscsit
    Alias             : -
    Sessions          : 0
#

The IQN will be different but similar since it is generated for the UID of the target host system.

Final check to make sure we are actually listening:

echo "::threadlist -v ! grep idmsosvcportwatcher" | mdb -k

If no threads are found, then reboot the system (this should only ever be a problem immediately after installation and should not be necessary at all for the FCS product).

  • Now you should be able to configure an initiator to connect to the target

On the initiator system (assuming Solaris):

# iscsiadm modify discovery -t disable
# iscsiadm add static-config iqn.1986-03.com.sun:02:80c3a500-ff15-e656-aee3-bc63d49b449d,<target IP address>

(** Modify IQN above to match the automatically generated IQN on the target)

# iscsiadm modify discovery -s enable

You should only really expect the Solaris initiator to work at this point although we will certainly test against a number of other initiators before FCS. Also the current code only supports static configuration so SendTargets discovery will not work.

  • At this point if there are any COMSTAR luns defined with unrestricted views (stmfadm add-view <GUID>) this luns should be visible to the initiator. If you need to create a lun follow the instructions here:
http://opensolaris.org/os/project/comstar/GettingStarted/

Known Issues

  1. If the connection is lost while iSCSI tasks are active then the resulting behavior is undefined — this could result in anything ranging from a memory leak to a kernel panic.
  2. itadm CLI is brand new and relatively untested. Multiple create/delete operations will likely work things into a bad state. It's best to just create the initial target and leave the CLI alone for now.
  3. Too much kernel spew. This will be removed at a future time. The kernel printfs are only related to connection establishment/shutdown so if these are seen it means something is happening with one of the connections.

Performance Issues

  • Read data is sent to the initiator in the context of the STMF worker thread. Since the socket send operations are blocking/synchronous this means the worker thread is stalled while the data is transferred. Planned fix: if the requested data transfer size is smaller than the total data transfer size for the data, dispatch the transfer to a task queue so it can be handled on another thread, releasing the worker thread to start another I/O to the backend. This issue would manifest itself as reduced read performance for large transfers (over 128k).
  • To work around an issue with serialization of the StatSN value in iSCSI responses the code currently grabs a mutex before the allocation of a new StatSN value and holds it until the PDU is transmitted. Since the PDU transmission is synchronous/blocking this mutex can be held for long periods of time. Yes, lockstat shows the lock is hot. Planned fix: PDU transmission will be broken into a two step process with step one obtaining a queue slot for the PDU and step two marking the PDU as ready for transmission.