lokesharo | 1 Jul 15:25 2015
Picon

iSNS Fail Over Mechanism

I would like to know about the fail over mechanisms used by iSNS for ISCSI implementation. The RFC states that "Note that it is possible to create multiple physical iSNS servers to form a single logical iSNS server cluster, and thus to distribute iSNS transaction processing among multiple physical servers. However, a more detailed discussion of the interactions between physical servers within a logical iSNS server cluster is beyond the scope of this document."

I tried searching but most of the findings are related to Windows and that too does not explain what are the fail over techniques used or the implementation details.

Any links or documents about the same would be very useful. Thanks

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Christian Iversen | 29 Jun 16:40 2015
Picon

8 patches for review

Hello Open-iSCSI

(please CC as I'm not a regular on the list)

I've been working with iSCSI lately, and thought I could help with a few
patches.

Here's a description:

--> 0001-Enable-MaxOutstandingR2T-negotiation-support-in-iscs.patch

This patch enables MaxOutstandingR2T negotiation for sessions. 
Currently, max_r2t negotiation is in a weird, half-broken state. The 
kernel seems to support max_r2t > 1 just fine (at least it connects), 
but iscsiadm is hard-coded to use "1", regardless of the setting that 
the user sets in the config file, which is very confusing.

I spent more time than I'd like to admit on tracking this one down.. :)

There's even error handling in place for max_r2t > 1, but this is never 
triggered since the value "1" is hard-coded, and the config file is 
ignored. This is the worst of both worlds.

--> 0002-Removed-a-number-of-unused-variables.patch

Quick cleanup, to fix a number of compiler warnings.

--> 0003-Removed-unused-variable-and-computation.patch

Same as 0002.

--> 0004-Added-missing-pointer-dereferencing-memset-would-onl.patch
--> 0005-Added-missing-pointer-dereferencing-memset-would-onl.patch

In the duplicate(!) md5 function MD5Final(), there is a final

memset(ctx, 0, sizeof(ctx));

to clear the context of sensitive data after MD5 calculation - which is 
fine.

Unfortunately, they both refer to sizeof(ctx), which is a pointer, 
effectively nullifying (no pun intended) the effect of memset(). This is 
changed to sizeof(*ctx).

--> 0006-Removed-unused-variable-one.patch
--> 0007-Removed-unused-variable-pdu_text.patch
--> 0008-Removed-dead-code.patch

Should be self-explanatory.

These are all more or less just compile-tested. Any comments?

-- 
De bedste hilsner / Best Regards,
Christian Iversen

System Engineer

Meebox ApS
Store Kongensgade 40H,
1264 KĂžbenhavn K
T: +45 3841 3841

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
LSZhu | 26 Jun 08:31 2015
Picon

May I do some contributions for iSCSI multiqueue

Hi,
I have been working for iSCSI in SUSE for half a year, I have some basic knowledge of iSCSI. I did some debug  and performance analyze work before.I am quite interested in iSCSI-mq, I am not a expert here, but may I do some contributions for iSCSI-mq? If you need me in somewhere, please let me know.

In my view, there seems such works need to be done:

(1) open-iscsi should simulate a multi-queue block device on the initiator side, I mean, /dev/sdc, sdd which simulated by open-iscsi should be multi-queue, just like we want a multi-queue hardware device as a backstore.
(2)  I/O scheduler is needed in the block layer for multi-queue, for the simulated device mentioned above.
(3) open-iscsi should establish more than one connections to the target in a session, and a  I/O scheduler is needed here.
(4) some performance improve work like how to manage multi-queue threads on multiple CPU cores, how to reduce latency, how to create a better pipeline.

I have heard that on the target LIO side, multi-queue work is done.
If I am wrong  somewhere, please tell me, I would appreciate for that.

I know you have did a lot of work for multi-queue, so if you need me somewhere, or I can help in some work, please let me know.

Thanks
BR
Zhu Lingshan

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Brian J. Murrell | 21 Jun 15:55 2015
Picon

recovering from a ping timeout, gracefully

So, clearly I have some kind of temporary/intermittent issues with my
network, unfortunately.  :-(  Fortunately they do seem to be
infrequently intermittent and most of the time things work.  But every
now and then I well get a spate of this:

Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection17:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082655665, last ping 5082660665, now 5082665665
Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection17:0: detected conn error (1011)
Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection24:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082655834, last ping 5082660834, now 5082665834
Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection24:0: detected conn error (1011)
Jun 19 15:08:40 eagle-4 iscsid: Kernel reported iSCSI connection 17:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:40 eagle-4 iscsid: Kernel reported iSCSI connection 24:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:40 eagle-4.eagle.hpdd.intel.com kernel: connection23:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082656608, last ping 5082661608, now 5082666608
Jun 19 15:08:40 eagle-4.eagle.hpdd.intel.com kernel: connection23:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection19:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657189, last ping 5082662189, now 5082667189
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection19:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection21:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657235, last ping 5082662235, now 5082667235
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection21:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection18:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657253, last ping 5082662253, now 5082667253
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection18:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4 iscsid: Kernel reported iSCSI connection 23:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection22:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657666, last ping 5082662666, now 5082667666
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection22:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection20:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657674, last ping 5082662674, now 5082667680
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection20:0: detected conn error (1011)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 19:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 21:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 18:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 22:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 20:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)

and then my ISCSI target it offline.  The network will recover very
shortly thereafter though and I can ping the tgtd server, etc.

What I wonder is, what is the most graceful way to tell the above
machine that things are repaired and to consider the target back in
service?  Currently after the above happens and even after the network
recovers, accessing the target returns an EIO, despite connectivity
being restored.  I'm assuming that this error state is persisted until
an operator can tell ISCSI otherwise.  But how does the operator do
that?

Surely it doesn't require tearing down the whole ISCSI infrastructure
and bringing it back up, does it?

Cheers,
b.

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Chris Leech | 17 Jun 01:07 2015
Picon

[PATCH] iSCSI: let session recovery_tmo sysfs writes persist across recovery

The iSCSI session recovery_tmo setting is writeable in sysfs, but it's
also set every time a connection is established when parameters are set
from iscsid over netlink.  That results in the timeout being reset to
the default value after every recovery.

The DM multipath tools want to use the sysfs interface to lower the
default timeout when there are multiple paths to fail over.  It has
caused confusion that we have a writeable sysfs value that seem to keep
resetting itself.

This patch adds an in-kernel flag that gets set once a sysfs write
occurs, and then ignores netlink parameter setting once it's been
modified via the sysfs interface.  My thinking here is that the sysfs
interface is much simpler for external tools to influence the session
timeout, but if we're going to allow it to be modified directly we
should ensure that setting is maintained.

Signed-off-by: Chris Leech <cleech@...>
---
 drivers/scsi/scsi_transport_iscsi.c | 11 ++++++++---
 include/scsi/scsi_transport_iscsi.h |  1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
index 67d43e3..35ef55f 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
 <at>  <at>  -2040,6 +2040,7  <at>  <at>  iscsi_alloc_session(struct Scsi_Host *shost, struct iscsi_transport *transport,
 	session->transport = transport;
 	session->creator = -1;
 	session->recovery_tmo = 120;
+	session->recovery_tmo_sysfs_override = false;
 	session->state = ISCSI_SESSION_FREE;
 	INIT_DELAYED_WORK(&session->recovery_work, session_recovery_timedout);
 	INIT_LIST_HEAD(&session->sess_list);
 <at>  <at>  -2784,7 +2785,8  <at>  <at>  iscsi_set_param(struct iscsi_transport *transport, struct iscsi_uevent *ev)
 	switch (ev->u.set_param.param) {
 	case ISCSI_PARAM_SESS_RECOVERY_TMO:
 		sscanf(data, "%d", &value);
-		session->recovery_tmo = value;
+		if (!session->recovery_tmo_sysfs_override)
+			session->recovery_tmo = value;
 		break;
 	default:
 		err = transport->set_param(conn, ev->u.set_param.param,
 <at>  <at>  -4047,13 +4049,15  <at>  <at>  store_priv_session_##field(struct device *dev,				\
 	if ((session->state == ISCSI_SESSION_FREE) ||			\
 	    (session->state == ISCSI_SESSION_FAILED))			\
 		return -EBUSY;						\
-	if (strncmp(buf, "off", 3) == 0)				\
+	if (strncmp(buf, "off", 3) == 0) {				\
 		session->field = -1;					\
-	else {								\
+		session->field##_sysfs_override = true;			\
+	} else {							\
 		val = simple_strtoul(buf, &cp, 0);			\
 		if (*cp != '\0' && *cp != '\n')				\
 			return -EINVAL;					\
 		session->field = val;					\
+		session->field##_sysfs_override = true;			\
 	}								\
 	return count;							\
 }
 <at>  <at>  -4064,6 +4068,7  <at>  <at>  store_priv_session_##field(struct device *dev,				\
 static ISCSI_CLASS_ATTR(priv_sess, field, S_IRUGO | S_IWUSR,		\
 			show_priv_session_##field,			\
 			store_priv_session_##field)
+
 iscsi_priv_session_rw_attr(recovery_tmo, "%d");

 static struct attribute *iscsi_session_attrs[] = {
diff --git a/include/scsi/scsi_transport_iscsi.h b/include/scsi/scsi_transport_iscsi.h
index 2555ee5..6183d20 100644
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
 <at>  <at>  -241,6 +241,7  <at>  <at>  struct iscsi_cls_session {

 	/* recovery fields */
 	int recovery_tmo;
+	bool recovery_tmo_sysfs_override;
 	struct delayed_work recovery_work;

 	unsigned int target_id;
-- 
2.1.0

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

adheer.chandravanshi | 16 Jun 14:52 2015

[PATCH] iscsiuio: Correct the handling of Multi Function mode

From: Adheer Chandravanshi <adheer.chandravanshi@...>

Handle the Multi Function mode correctly when dealing with bnx2x driver.

Signed-off-by: Adheer Chandravanshi <adheer.chandravanshi@...>
---
 iscsiuio/src/unix/libs/bnx2x.c |   23 ++++++++++++++++-------
 1 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/iscsiuio/src/unix/libs/bnx2x.c b/iscsiuio/src/unix/libs/bnx2x.c
index 1495762..a364d76 100644
--- a/iscsiuio/src/unix/libs/bnx2x.c
+++ b/iscsiuio/src/unix/libs/bnx2x.c
 <at>  <at>  -672,6 +672,9  <at>  <at>  static int bnx2x_open(nic_t *nic)
 	uint32_t bus;
 	uint32_t slot;
 	uint32_t func;
+	uint32_t mode;
+	__u32 proto_offset;
+	__u32 ovtag_offset;

 	/*  Sanity Check: validate the parameters */
 	if (nic == NULL) {
 <at>  <at>  -1002,9 +1005,11  <at>  <at>  static int bnx2x_open(nic_t *nic)
 			mf_cfg_addr = bp->shmem_base + 0x7e4;

 		/* shared_feat_cfg.config */
-		val = bnx2x_rd32(bp, bp->shmem_base + 0x354);
-		/* SI mode */
-		if ((val & 0x700) == 0x300) {
+		mode = bnx2x_rd32(bp, bp->shmem_base + 0x354);
+		mode &= 0x700;
+		LOG_DEBUG(PFX "%s: mode = 0x%x", nic->log_name, mode);
+		switch (mode) {
+		case 0x300: /* SI mode */
 			mac_offset = 0xe4 + (bp->func * 0x28) + 4;
 			val = bnx2x_rd32(bp, mf_cfg_addr + mac_offset);
 			mac[0] = (__u8) (val >> 8);
 <at>  <at>  -1027,9 +1032,13  <at>  <at>  static int bnx2x_open(nic_t *nic)
 				rc = -ENOTSUP;
 				goto open_error;
 			}
-		} else if ((val & 0x700) == 0) {
-			__u32 proto_offset = 0x24 + (bp->func * 0x18);
-			__u32 ovtag_offset = proto_offset + 0xc;
+			break;
+
+		case 0x0: /* MF SD mode */
+		case 0x500:
+		case 0x600:
+			proto_offset = 0x24 + (bp->func * 0x18);
+			ovtag_offset = proto_offset + 0xc;

 			rc = -ENOTSUP;
 			val = bnx2x_rd32(bp, mf_cfg_addr + ovtag_offset);
 <at>  <at>  -1057,7 +1066,7  <at>  <at>  static int bnx2x_open(nic_t *nic)
 			mac[4] = (__u8) (val >> 8);
 			mac[5] = (__u8) val;
 			memcpy(nic->mac_addr, mac, 6);
-
+			break;
 		}
 	}
 SF:
-- 
1.7.1

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Hannes Reinecke | 10 Jun 08:32 2015
Picon

[PATCH] firmware: ACPI iBFT firmware support on EFI machines

The iBFT firmware tables can also be specified via ACPI tables
when using EFI firmware. The 'iscsi_ibft_find' module is only
for legacy X86 BIOS, so it needs to be skipped for all other
architectures.

Signed-off-by: Hannes Reinecke <hare@...>
---
 drivers/firmware/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6517132..79204b2 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
 <at>  <at>  -124,7 +124,7  <at>  <at>  config ISCSI_IBFT_FIND
 config ISCSI_IBFT
 	tristate "iSCSI Boot Firmware Table Attributes module"
 	select ISCSI_BOOT_SYSFS
-	depends on ISCSI_IBFT_FIND && SCSI && SCSI_LOWLEVEL
+	depends on (ISCSI_IBFT_FIND || ACPI) && SCSI && SCSI_LOWLEVEL
 	default	n
 	help
 	  This option enables support for detection and exposing of iSCSI
-- 
1.8.5.2

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

takfaisze | 8 Jun 18:45 2015
Picon

add or remove targets without restarting open-iscsi when use_discoveryd=Yes

When open-iscsi is running with use_discoveryd=YES, one has to restart open-iscsi when targets are added or removed:

1. Add a target:

    a. iscsiadm -m discoverydb -o new -p 1.1.1.1 -t st -l
    b. iscsiadm -m discoverydb -p 1.1.1.1  -t st -o update -n discovery.sendtargets.use_discoveryd -v Yes
    c. /etc/init.d/open-iscsi restart

2. Remove target:
  
 a. iscsiadm -m discoverydb -p 1.1.1.1  -t st -o delete
    b. /etc/init.d/open-iscsi restart


Is there a way to have open-iscsi pick the new targets without restarting open-iscsi, i.e. I do not want to touch any existing sessions for targets that I didn't remove and be able to pick up new targets that are put into the discovery mode?

Also, is there a way to logoff a specific target with use_discoveryd=YES. I can logoff via iscsiadm -m session, but the session is re-established after the discoveryd poll interval.

- Tak

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
allspace | 4 Jun 16:19 2015
Picon

iscsistart compatibility with kernel

Dear all,

Does the most recent iscsistart (compiled from latest source code) works with all kernel versions since 2.6.16?

or to run iscsistart with a kernel, it must be compiled on that kernel?

I want to have one iscsistart binary work with all kernels since 2.6.16.


Thanks
Mike

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
allspace | 6 Jun 15:01 2015
Picon

iscsid/iscsistart and kernel version compatibility

Hi,

It seems iscsistart/iscsid somehow relies on specific kernel version. 

Is there any document about which iscsistart/iscsid version matches which kernel version. I am considering use one iscsistart/iscsid for multiple kernel versions. I cannot compile iscsistart/iscsid for every kernel version that I want to support.

Mike

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
allspace | 6 Jun 14:56 2015
Picon

iscsistart and iscsid

Hi,

I run iscsistart in initrd to bring up all iscsi disks (include root disk).
After switch root, do I still need run iscsid service, considering I have no need to run iscsiadm for administration operations.

Mike

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Gmane