[stgt] stgt does not preempt SCSI-2 reservations; may break MS Cluster Service failover

Florian Haas florian.haas at linbit.com
Mon Aug 31 09:31:45 CEST 2009

Fujita-san et al,

I am running into a situation where somewhat unexpected tgtd behavior
seems to break failover for a MS Cluster Service cluster on Windows 2003
with Microsoft iSCSI initiator 2.08.

Please consider the following scenario:

- 4-node MSCS cluster is configured to use a tgtd-exported LU as its
quorum device.
- The active node in the cluster reserves that LU via a SCSI-2
reservation (RESERVE).
- Manual failover (including the associated SCSI-2 RELEASE) has been
established  to work as expected.
- The currently active node has its iSCSI connection broken by removal
of the Ethernet cable.
- After the Time2Retain expires, MSCS initiates automatic failover to
one of the surviving peer nodes.
- The node taking over now attempts to preempt the reservation on the
quorum disk, by issuing a bus reset and then RESERVE.
- The bus reset appears to fail.
- Thus, the node taking over cannot RESERVE, and failover effectively

Looking at what I think is the relevant code path in
I see this:

1319                 fn = LOGICAL_UNIT_RESET;
1320                 break;
1323         case ISCSI_TM_FUNC_TASK_REASSIGN:
1324                 err = ISCSI_TMF_RSP_NOT_SUPPORTED;
1325                 break;

So it appears that if the initiator does not issue an LU reset, but
instead a bus reset (and MSCS seems to exhibit that behavior, at least
in Windows 2003), then this preemption method is bound to fail.

Interestingly, ietd appears to handle this correctly. Again, I'm just
guessing that this is the correct code path to look into, but in
http://svn.berlios.de/wsvn/iscsitarget/trunk/kernel/iscsi.c, it seems
that in execute_task_management(), ISCSI_FUNCTION_TARGET_WARM_RESET and
ISCSI_FUNCTION_TARGET_COLD_RESET are mapped to the target_reset()
function and thus handled correctly.

Could you please explain whether my analysis of the situation is
correct, and if so: what is the reason for not supporting target resets
in tgtd, and what is it that precludes supporting it?

Many thanks in advance,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wpkg.org/pipermail/stgt/attachments/20090831/0bcfd7b8/attachment.sig>

More information about the stgt mailing list