On Wed, 08 Jul 2009 17:48:21 +0200
Florian Haas <florian.haas@xxxxxxxxxx> wrote:
> OK, issue solved. Sort of.
>
> Here's what happens:
>
> - Target moves from one cluster node to another.
>
> - Windows iSCSI initiator reconnects to target.
>
> - Immediately after login, iSCSI initiator issues REPORT LUNs.
>
> - Then for every LUN, iSCSI initiator issues INQUIRY for VPN pages 0x80
> and 0x83.
>
> - If the device ID or serial number of _any_ device do not match what
> the iSCSI initiator has cached, then it does a REPORT LUNs again, and
> not only INQUIRY on every LU, but also Read Capacity, Mode Sense, etc.
> It just does a full bus rescan.
>
> Now, I had thought of using explicitly defined scsi_id and scsi_sn for
> all my LUs. What I hadn't thought of is that the Windows iSCSI initiator
> also looks at LUN 0, and that LU I can't modify in STGT. Thus, I can't
> set a custom serial number. And if the target ID happens to change on
> failover, then the serial number of the "controller" LU changes and
> Windows gets horribly confused.
>
> IET doesn't have this issue simply because there LUN 0 is a regular disk LU.
Thanks for the useful information.
> I guess I'll work around this in my Pacemaker RA, but would it be a huge
> problem if you could make the SCSI SN and SCSI ID of the "controller" LU
> configurable from userland, just like for regular disk LUs?
It's a bug if we can't configure lun0. I've attached a fix.
diff --git a/usr/tgtadm.c b/usr/tgtadm.c
index 78e817c..21e709a 100644
--- a/usr/tgtadm.c
+++ b/usr/tgtadm.c
@@ -430,7 +430,9 @@ int main(int argc, char **argv)
struct tgtadm_req *req;
op = tid = mode = -1;
- total = cid = hostno = sid = lun = 0;
+ total = cid = hostno = sid = 0;
+ lun = UINT64_MAX;
+
rc = 0;
dev_type = TYPE_DISK;
ac_dir = ACCOUNT_TYPE_INCOMING;
@@ -678,7 +680,7 @@ int main(int argc, char **argv)
eprintf("'tid' option is necessary\n");
exit(EINVAL);
}
- if (!lun) {
+ if (lun == UINT64_MAX) {
eprintf("'lun' option is necessary\n");
exit(EINVAL);
}
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
