Antw: [PATCH v2 1/2] iscsid: Changes to support ping through iscsiuio
adheer.chandravan...@qlogic.com schrieb am 09.07.2015 um 13:38 in
Nachricht
1436441896-7161-2-git-send-email-adheer.chandravan...@qlogic.com:
From: Adheer Chandravanshi adheer.chandravan...@qlogic.com
These changes are done in order to support ping operation for drivers
like bnx2i that use iscsiuio.
Signed-off-by: Adheer Chandravanshi adheer.chandravan...@qlogic.com
---
usr/iscsiadm.c | 38 +++---
usr/iscsid_req.c | 38 +-
usr/iscsid_req.h |2 +-
usr/transport.c|1 +
usr/transport.h|3 +++
usr/uip_mgmt_ipc.c | 38 +-
usr/uip_mgmt_ipc.h | 13 +
7 files changed, 119 insertions(+), 14 deletions(-)
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c
index aa7cf07..495af3a 100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -3099,10 +3099,10 @@ static char *iscsi_ping_stat_strs[] = {
No ARP response received,
};
-static char *iscsi_ping_stat_to_str(uint32_t status)
+static char *iscsi_ping_stat_to_str(int status)
{
if (status 0 || status ISCSI_PING_NO_ARP_RECEIVED) {
- log_error(Invalid ping status %u, status);
+ log_error(Ping error: %s\n, strerror(status));
status does not look very much like errno, but isn't strerror() defined for
errno values?
return NULL;
}
[...]
Regards,
Ulrich
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Re: iSNS Fail Over Mechanism
Hi Thanks for the response. the above mentioned text is a part of the description given by RFC. Please find below the other part. So the RFC states the below mentioned text for fail over. And apart from the method of listening to the heart beat messages it also mentions that fail over mechanism is possible but not explained fully in this document. The RFC says: Server failover and recovery are topics of continuing research, and adequate resolution of issues such as split brain and primary server selection is dependent on the specific implementation requirements and deployment needs. The failover mechanisms discussed in this document focus on the interaction between iSNS clients and iSNS servers. Specifically, what is covered in this document includes the following: - iSNS client behavior and the iSNS protocol interaction between the client and multiple iSNS servers, some of which are backup servers. - Required failover behaviors of the collection of iSNS servers that includes active and backup servers. *However*, note that this document does not specify the complete functional failover requirements of each iSNS server. In particular, it does not specify the complete set of protocol interactions among the iSNS servers that are required to achieve stable failover operation in an interoperable manner. I know it says that the above mentioned details are implementation specific but I would like to know these implementations as I myself have some ideas regarding the same and need to know the current implementation methods. Thanks Lokesh On Sat, Jul 4, 2015 at 4:00 AM, The Lee-Man leeman.dun...@gmail.com wrote: On Thursday, July 2, 2015 at 2:17:12 AM UTC-7, loke...@gmail.com wrote: 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 It does not sound like the method mentioned by the RFC was meant for fail-over, but instead was meant to distribute the work. And I can't imagine an iSNS workload so large a single system could not handle it. But perhaps I think too small. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
[PATCH] iBFT 'origin' is an enum, not a string
From: Lee Duncan ldun...@suse.com The iBFT 'origin' value is read in one place correctly as an integer. This fixes the place where it was treated as a string. --- utils/fwparam_ibft/fwparam_ibft_sysfs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/utils/fwparam_ibft/fwparam_ibft_sysfs.c b/utils/fwparam_ibft/fwparam_ibft_sysfs.c index 2dc6f6d5fe54..019fc19184bb 100644 --- a/utils/fwparam_ibft/fwparam_ibft_sysfs.c +++ b/utils/fwparam_ibft/fwparam_ibft_sysfs.c @@ -201,8 +201,7 @@ static int fill_nic_context(char *id, struct boot_context *context) sizeof(context-secondary_dns)); sysfs_get_str(id, IBFT_SUBSYS, dhcp, context-dhcp, sizeof(context-dhcp)); - sysfs_get_str(id, IBFT_SUBSYS, origin, context-origin, - sizeof(context-origin)); + sysfd_get_int(id, IBFT_SUBSYS, origin, context-origin); return 0; } -- 2.1.4 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
[PATCH] Read iBFT 'origin' as an integer, not a string
From: Lee Duncan ldun...@suse.com Recent patches have added support for iBFT 'origin' when determining the source of the iBFT boot IP Address, but this value is an enum (integer), not a string. This patch fixes the one place it was read as a string. Lee Duncan (1): iBFT 'origin' is an enum, not a string utils/fwparam_ibft/fwparam_ibft_sysfs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.1.4 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: iSNS Fail Over Mechanism
On Friday, July 10, 2015 at 6:12:34 AM UTC-7, lokesharora wrote: Hi Thanks for the response. the above mentioned text is a part of the description given by RFC. Please find below the other part. So the RFC states the below mentioned text for fail over. And apart from the method of listening to the heart beat messages it also mentions that fail over mechanism is possible but not explained fully in this document. The RFC says: Server failover and recovery are topics of continuing research, and adequate resolution of issues such as split brain and primary server selection is dependent on the specific implementation requirements and deployment needs. The failover mechanisms discussed in this document focus on the interaction between iSNS clients and iSNS servers. Specifically, what is covered in this document includes the following: - iSNS client behavior and the iSNS protocol interaction between the client and multiple iSNS servers, some of which are backup servers. - Required failover behaviors of the collection of iSNS servers that includes active and backup servers. *However*, note that this document does not specify the complete functional failover requirements of each iSNS server. In particular, it does not specify the complete set of protocol interactions among the iSNS servers that are required to achieve stable failover operation in an interoperable manner. I know it says that the above mentioned details are implementation specific but I would like to know these implementations as I myself have some ideas regarding the same and need to know the current implementation methods. Thanks Lokesh I just rescanned the open-isns code here: https://github.com/gonzoleeman/open-isns -- this is supposed to be the official home of open-isns. There is only one mention of failover, and it's in the TODO file: ... Heartbeat: - Implement message send - Implement failover? ... So it looks like it's a known issue. Sounds like it's wide open, if you want to submit patches to fix that. Right now I am trying to get open-isns in sync with open-iscsi, but as soon as that's done I would entertain a set of patches that would address this. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
