Re: open-iscsi read path getting stuck, tcp_read_sock not calling recv_actor.

[The Lee-Man]

Narender:

I work for SUSE. Please file a SUE bug on this, and please cc me - my work 
email is lduncan at novell dot com.

I have a similar setup, i.e. booted SLES 11 SP2 using iSCSI, but I have 
seen no such errors. When you file the bug, please include log messages and 
a list of initiator HBA type (i.e. network, iBFT, iSCSI CNA, etc)

The patch mentioned in this thread is essentially already in SLES, so that 
cannot be the problem (though it may be similar).

One question off the top of my head: do you have the latest SLES 11 SP2 
updates?

On Thursday, June 21, 2012 5:39:25 AM UTC-7, narender wrote:

 Am using open-iscsi on Suse 10.2, while doing IO, in receive path, the 
 function iscsi_sw_tcp_recv is not getting called by the tcp_read_sock 
 function. It manifests in the receive path (Data-in PDUs processing) but 
 does not always happens at the same moment every time I have put some 
 printks in the kernel for debugging and I can see that data is available in 
 the socket to be read and socket state is also normal, but tcp_read_sock is 
 not calling the function iscsi_sw_tcp_recv to receive the data. The 
 recv_actor function is not getting invoked after a point in time. 
 Any pointers in this regard will be highly appreciated.


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/open-iscsi/-/u8ayudRyzzQJ.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: open-iscsi read path getting stuck, tcp_read_sock not calling recv_actor.

[The Lee-Man]

s/SUE bug/SUSE bug/

On Wednesday, June 27, 2012 3:26:25 PM UTC-7, The Lee-Man wrote:

 Narender:

 I work for SUSE. Please file a SUE bug on this, and please cc me - my work 
 email is lduncan at novell dot com.

 I have a similar setup, i.e. booted SLES 11 SP2 using iSCSI, but I have 
 seen no such errors. When you file the bug, please include log messages and 
 a list of initiator HBA type (i.e. network, iBFT, iSCSI CNA, etc)

 The patch mentioned in this thread is essentially already in SLES, so that 
 cannot be the problem (though it may be similar).

 One question off the top of my head: do you have the latest SLES 11 SP2 
 updates?


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/open-iscsi/-/72kzp7oGFW8J.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: suse iscsi devices

[The Lee-Man]

Mark:

Did Mike answer your questions? If not, I'd be glad to help on the SUSE 
part.


On Wednesday, February 20, 2013 10:37:57 AM UTC-8, Blaxton, Mark H wrote:

  Question: I’ve configure the iscsi iniator on my suse 11 system and its 
 connected to my target but lsscis doesn’t show any new devices?  Anyone had 
 any

 Experience with not seeing the devices? 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+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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

IPv6 Discovery on 2.0.873-suse

[The Lee-Man]

Hi Mike:

I am testing the new version of open-iscsi on SLES 11 SP3 Beta.
This is the update I did to support IPv6, with your help.

I am validating the IPv6 functionality, and I seem to be experiencing
double-discovery of my IPv6 target.

My setup: I have an iscsitarget soft target. The IPv6 Link-local address
of that node is fe80::221:ccff:fe6f:1a11.

When I run the discovery command:

iscsiadm -m discovery -t st -p fe80::221:ccff:fe6f:1a11

I get the same node discovered twice:

[fe80::221:ccff:fe6f:1a11]:3260,1 
iqn.2001-04.net.gonzoleeman:test.disk.laptop.001
[fe80::221:ccff:fe6f:1a11]:3260,1 
iqn.2001-04.net.gonzoleeman:test.disk.laptop.001

If I happen to run the discovery command with -l, I get two sessions
connected to the same target -- not what I intended.

I have the output from running the discovery command with -d 8,
but it is 32k, so I hesitate to include it inline.

My interface file for this is in /etc/iscsi/ifaces/em1-ipv6, contents:

face.net_ifacename = em1
face.ipaddress = fe80::92b1:1cff:fe80:660f
iface.transport_name = tcp
iface.state = enable

Another note: when I use IPv6 discovery on this same target, I get only
one discovery record.

Any idea why I am getting this IPv6 double discovery?
Am I using the interface file incorrectly?
-- 
Lee Duncan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH 1/3] iscsiadm: Add flash node mgmt support.

[The Lee-Man]

On Thursday, May 9, 2013 5:03:44 AM UTC-7, Adheer Chandravanshi wrote:

  -Original Message- 
  From: Mike Christie [mailto:mich...@cs.wisc.edu javascript:] 
  Sent: Thursday, May 09, 2013 7:31 AM 
  To: open-...@googlegroups.com javascript: 
  Cc: The Lee-Man; Vikas Chaudhary; Lalit Chandivade; Ravi Anand; Poornima 
  Vonti; Manish Rangankar; Adheer Chandravanshi 
  Subject: Re: [PATCH 1/3] iscsiadm: Add flash node mgmt support. 
  
  On 05/08/2013 05:52 PM, The Lee-Man wrote: 
   
   -if (name  value) { 
   +if ((mode == MODE_IFACE || 
   + (mode == MODE_HOST  sub_mode == 
   MODE_FLASHNODE))  
   +name  value) { 
param = idbm_alloc_user_param(name, 
 value); 
if (!param) { 
log_error(Cannot allocate memory 
   for params.); 
   
   
   I believe this is incorrect. After your patch, name and value will 
   not be set in MODE_NODE. 
   
   Should that be if (mode == MOD_IFACE || mode == MODE_NODE || ? 
   
   @@ -2603,7 +3007,7 @@ main(int argc, char **argv) 
  
  Thank you so much for helping to review! You are right. 

 Mike, 

 Please find the patch attached herewith that fixes the issue reported by 
 Lee. 

 Thanks, 
 Adheer 



Looks good to me, and tested as well.

Acked-by: Lee Duncan leeman.dun...@mail.com 



  

 This message and any attached documents contain information from QLogic 
 Corporation or its wholly-owned subsidiaries that may be confidential. If 
 you are not the intended recipient, you may not read, copy, distribute, or 
 use this information. If you have received this transmission in error, 
 please notify the sender immediately by reply e-mail and then delete this 
 message. 


-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATH 0 of 1] Fix check for nice() return value

[The Lee-Man]

Apologies for Subject formatting errors ... I need to wean myself off of OS 
X ...

On Tuesday, May 21, 2013 2:15:00 PM UTC-7, The Lee-Man wrote:

 I mentioned this before, but I didn't have a good solution at the time. 

 In usr/iscsi_util.c, nice() is called like this: 

 if (nice(-10)  0) 
 log_debug(...) 

 The problem is that nice() returns the current nice value, 
 and that value can legitimately be less than zero, in which 
 case a spurious log message is generated. 

 Although I don't like setting errno directly except when in a 
 library, the nice(2) man page actually suggests this as the 
 best way to fix the problem. 

 Therefore, the supplied patch is designed to fix this problem. 

 -- 
 Ignore the Lee-Man behind the curtain ... 

  Life's a long song. But the tune ends too soon for 
 us all. -- Ian Anderson 



-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [systemd-devel] [RFC] iscsid / systemd / dracut integration effort

[The Lee-Man]

On Tuesday, December 11, 2012 3:26:46 PM UTC-8, Chris Leech wrote:

 ...

 Thanks, this got me going in the right direction.  These unit files 
 seems to be working much better for me, with the startup and shutdown 
 ordering between iscsi, iscsid, and remote-fs mounts sorted out.  I'm 
 not sure about the tgtd/targetcli stuff, not sure what the original need 
 there was. 



I just wanted to post a thank you for all of this work, as I was attempting 
to do some of it myself and making slow progress.

I am trying to get open-iscsi version 2.0-873-suse working on openSUSE.

In my case open-iscsi-based boot is not working and has not been working 
for a while. In addition, we have an initrd-based boot, and it looks like 
that will have to change before iscsid-based booting can work correctly. 
Because of that, I did not try to get iscsi-root volumes working. My goal 
was to get normal non-root open-iscsi working with systemd as well as it 
had with SysV-based init (or better).

Toward that end, I have 3 unit files that are working on openSUSE 12.3 that 
I thought I would share. I am not submitting these as patches, since the 
whole systemd-integration effort is still in flux.

Using the systemd configuration below, iscsid is not started until needed. 
NOTE: I think we need a new mode in iscsid that goes away when it's work is 
done, since it can now be socket-activated (i.e. it doesn't have to sit 
there and wait for work).


Submitted for your comments:


iscsid.socket:
==
Unit]
Description=Open-iSCSI iscsid Socket
Documentation=man:iscsid(8) man:iscsiadm(8)

[Socket]
ListenStream=@ISCSIADM_ABSTRACT_NAMESPACE

[Install]
WantedBy=sockets.target



iscsid.service:
===
[Unit]
Description=Open-iSCSI
Documentation=man:iscsid(8) man:iscsiadm(8)
After=network.target NetworkManager-wait-online.service tgtd.service 
targetcli.service

[Service]
Type=forking
PIDFile=/var/run/iscsid.pid
ExecStart=/sbin/iscsid

[Install]
WantedBy=multi-user.target



iscsi.service:
==
[Unit]
Description=Login and scanning of iSCSI devices
Documentation=man:iscsiadm(8) man:iscsid(8)
After=network.target NetworkManager-wait-online.service iscsid.service
ConditionPathExists=/etc/iscsi/initiatorname.iscsi

[Service]
Type=oneshot
ExecStart=/sbin/iscsiadm -m node --loginall=automatic
ExecStop=/bin/sync
ExecStop=/sbin/iscsiadm -m session --logout
SuccessExitStatus=21
RemainAfterExit=true

[Install]
WantedBy=remote-fs.target

-- 
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/groups/opt_out.

Re: [systemd-devel] [RFC] iscsid / systemd / dracut integration effort

[The Lee-Man]

On Monday, September 23, 2013 10:33:36 AM UTC-7, The Lee-Man wrote:

 ...
 I just wanted to post a thank you for all of this work, as I was 
 attempting to do some of it myself and making slow progress.

 ...



Wanted to mention I also had to port back a couple of systemd-support 
patches for iscsid scoket use, as well.

-- 
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/groups/opt_out.

Re: [systemd-devel] [RFC] iscsid / systemd / dracut integration effort

[The Lee-Man]

On Friday, September 27, 2013 3:41:18 AM UTC-7, Per Jessen wrote:

 Per Jessen wrote: 

  The Lee-Man wrote: 
  
  I am trying to get open-iscsi version 2.0-873-suse working on 
  openSUSE. 
  
  In my case open-iscsi-based boot is not working and has not been 
  working for a while. 
  
  Just fyi, it works very well here, with 12.2, 12.3 and just now 
  13.1b1. 

 Actually, it does require a bit of fiddling (manual iscsi config, build 
 initrd) depending on your setup. 



Thanks Per.

For those that care: changes submitted to openSUSE Factory. After 
validation, changes will be aimed at openSUSE 13.1.

I believe openSUSE Factory will soon have dracut support, so the full 
iSCSI-root-volume support should follow.

-- 
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/groups/opt_out.

Parallel Discovery?

[The Lee-Man]

Hi Mike:

I have a configuration where discovery is taking a long time because one of 
the interfaces is disconnected.

Since it is not possible to reliably detect when an interface is connected, 
I thought the best way to speed up discovery in such cases would be for 
discovery to take place in parallel.

In looking at the code, it seems like node discovery could be done in 
parallel with a little work. In searching the archives, I found a thread 
where it looks like you wanted to make discovery in parallel, but that was 
a while ago.

Before I start hacking on the code to see what I can do, I wondered if you 
have any ideas on the best way to do this, or even if it is a good idea at 
all.

With only 2 or 3 interfaces, this is not a big deal, but I could see a case 
where a dozen interfaces could mean a very slow discovery process.
--
Lee Duncan

-- 
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/groups/opt_out.

Re: [PATCH 1/1] Bug fix on IPC address copy

[The Lee-Man]

On Thursday, November 14, 2013 11:09:37 PM UTC-8, Uli wrote:

  mich...@cs.wisc.edu javascript: schrieb am 15.11.2013 um 00:53 in 
 Nachricht 
 1384473233-4711-1-git-send-email-micha...@cs.wisc.edu javascript:: 
  From: Yufei Ren yufe...@stonybrook.edu javascript: 
  
  Got can not connect to iSCSI daemon (111)! error during 
  starting iscsi service by: 
  $ iscsiadm -m node --loginall=all 
  
  Traced down and found that the sun_path was mis-used in both iscsid 
  and iscsiadm. 
  --- 
   usr/iscsid_req.c |2 +- 
   usr/mgmt_ipc.c   |2 +- 
   2 files changed, 2 insertions(+), 2 deletions(-) 
  
  diff --git a/usr/iscsid_req.c b/usr/iscsid_req.c 
  index 715c0aa..0ebde90 100644 
  --- a/usr/iscsid_req.c 
  +++ b/usr/iscsid_req.c 
  @@ -71,7 +71,7 @@ static int ipc_connect(int *fd, char *unix_sock_name, 
 int 
  start_iscsid) 

   memset(addr, 0, sizeof(addr)); 
   addr.sun_family = AF_LOCAL; 
  -memcpy((char *) addr.sun_path + 1, unix_sock_name, 
  +memcpy((char *) addr.sun_path + 1, unix_sock_name, 
  strlen(unix_sock_name)); 

 A note on style: If you do a memcpy() with strlen() as length argument, 
 why not use plain strcpy()? It's even more efficient... 


[Almost] Never do a strcpy(). Always use strncpy() unless you have 
unlimited space, or you know for certain how long the source string is 
already.
 



   /* 
  diff --git a/usr/mgmt_ipc.c b/usr/mgmt_ipc.c 
  index 87bd346..6a422b9 100644 
  --- a/usr/mgmt_ipc.c 
  +++ b/usr/mgmt_ipc.c 
  @@ -63,7 +63,7 @@ mgmt_ipc_listen(void) 

   memset(addr, 0, sizeof(addr)); 
   addr.sun_family = AF_LOCAL; 
  -memcpy((char *) addr.sun_path + 1, ISCSIADM_NAMESPACE, 
 addr_len); 
  +memcpy((char *) addr.sun_path + 1, ISCSIADM_NAMESPACE, 
 addr_len); 

   if ((err = bind(fd, (struct sockaddr *) addr, addr_len))  0 ) 
 { 
   log_error(Can not bind IPC socket); 
  -- 
  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+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/groups/opt_out.

Re: iSCSI request keep rejected by microsoft iSCSI target because of write_same check

[The Lee-Man]

On Thursday, January 9, 2014 10:38:15 AM UTC-8, Mike Christie wrote:

 ...

  There are some questions: 
  1. Why stgt target don't has this issue? Does it support report_opcode 
  because it has a embeded controller lun0? Or it just returns INVALID in 
  response? 

 Don't know. Will let someone else that works on stgt respond. 


I just checked https://github.com/fujita/tgt, and it looks like tgtd does 
indeed handle REPORT_SUPPORTED_OPCODES. 

-- 
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/groups/opt_out.

Re: [PATCH]: 0/3: open-iscsi cleanup, and iBFT booting

[The Lee-Man]

Thanks Mike. Yes, it appears you're right, iscsi_offload is something Hannes
created. Should I add it someplace in your tree for possible use by others?

On Thursday, September 4, 2014 4:18:31 PM UTC-7, Mike Christie wrote:

 On 09/04/2014 04:10 PM, Lee Duncan wrote: 
  I'm attaching 3 patches for open-iscsi, created by Hannes. 
  
  The first patch cleans up an unused variable (a newer version of the 
 compiler complained), 
  and the other two patches help get iBFT-boot working. 
  
  Please let me know if I need to submit them inline rather than as 
 attachments. 
  

 This should be ok. I have merged the first 2 patches. They are in github 
 as 
 78e24f50ab754f35f4aa208ade7c9fd794d82036 
 21a7923de5b2f968643c2ffd96e5c9fb1b201fa3 

 The 3rd patch looks like it is suse specific. I do not see a 
 iscsi_offload script upstream. 





-- 
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: [PATCHES] Fixup iBFT and IPv6, some cleanup

[The Lee-Man]

On Tuesday, November 11, 2014 6:11:51 PM UTC-8, Mike Christie wrote:

 On 10/30/2014 08:16 PM, The Lee-Man wrote: 
  0003-fwparam_ibft-Check-iBFT-target-and-NIC-flags.patch 
  
  This was the patch that you had problems with last time, and 
  for good reason, as it checks iBFT flags for Bit-0, as per the 
  iBFT standard, but as you pointed out many adapters don't 
  follow the standard and instead set Bit-1. So now we just check 
  for any bit being set. This *has* been tested with more adapters. 

 Did you by any chance take note of what cards do what? Mostly interested 
 in bnx2i, cxgb*i, intel, and the ibm boxes with the initiator on them. 


No, I'm afraid I'm still trying to build up a library of relevant cards, 
since I
only have a few.
 


 If you do not know, do not worry. Just wanted to document it somewhere 
 if we knew. 




-- 
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: [PATCHES] Fixup iBFT and IPv6, some cleanup

[The Lee-Man]

On Friday, November 14, 2014 9:12:41 AM UTC-8, Mike Christie wrote:


 On Nov 13, 2014, at 5:56 PM, The Lee-Man leeman...@gmail.com 
 javascript: wrote:

 On Tuesday, November 11, 2014 8:25:56 PM UTC-8, Mike Christie wrote:

 On 10/30/2014 08:16 PM, The Lee-Man wrote: 
  0002-Represent-DHCP-origin-as-an-integer-not-string.patch 
  
  This just changes the origin attribute from a string, to a 
 number, 
  which 
  is what it really is. 
  

 Could you send me a link to where origin is defined? In the doc I have 
 it is a dead link. 


 This is defined in the iBFT document, available here on the web here: iBFT 
 Layout - Microsoft 
 http://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1ved=0CCAQFjAAurl=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F7%2FE%2F7%2F7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2%2FiBFT.docxei=TjZlVKeNKYzVoASDn4GAAwusg=AFQjCNHY7NV8Y8wg4cHMzEOHi-4oUnWNLQsig2=9mkbWXrDlIra2lY3Qbe-Vgbvm=bv.79400599,d.cGU
 (if my hper-link works)

 In section 3.6 NIC Structure, the table shows that origin 1 byte long at 
 offset 23 bytes. And table points at a C++ definition of the values here: 
 http://msdn.microsoft.com/en-us/library/aa366281.aspx

 It looks like:

 typedef enum  { 
   IpPrefixOriginOther= 0,
   IpPrefixOriginManual,
   IpPrefixOriginWellKnown,
   IpPrefixOriginDhcp,
   IpPrefixOriginRouterAdvertisement,
   IpPrefixOriginUnchanged= 16
 } IP_PREFIX_ORIGIN;

 The open-iscsi code current checks this for the value 3 (i.e. a string 
 representing the number 3), and our code already has a patch that instead 
 reads this value in as an integer, and then compares it with the number 3.

 Could you add a enum for these values in fw_context.h and then check for 
 it instead of the numerical value?


I will submit the set again against current 'master' branch, minus patch 4 
(for now). 

-- 
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.

[PATCHESv2] Fixup iBFT and IPv6, some cleanup

[The Lee-Man]

Hi Mike:

Here are the updated patches, based on your feedback:

0001-Code-cleanup-no-functional-changes.patch
0002-Represent-DHCP-origin-as-an-enum-not-a-string.patch
0003-fwparam_ibft-Check-iBFT-target-and-NIC-flags.patch
0004-Allow-modifications-for-iface.gateway-and-iface.subn.patch

Changes from last version:

patch 2: uses an enum now. Not sure if the state should be kept as an
integer or an enum. feedback welcome

also, the original path 4 was removed, for later discussion (once we get 
prefix-len figured out).

Patches are attached (since the groups.google.com interface doesn't easily 
do plain text)

Thanks.
-- 
Lee Duncan

-- 
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.
From 7517894b701e13f43aafb0dc7f8301a53cf67d97 Mon Sep 17 00:00:00 2001
From: Hannes Reinecke h...@suse.de
Date: Wed, 29 Oct 2014 11:03:56 -0700
Subject: [PATCH 1/4] Code cleanup: no functional changes

---
 usr/iface.c| 3 ++-
 utils/fwparam_ibft/fw_entry.c  | 8 
 utils/fwparam_ibft/fwparam_sysfs.c | 4 ++--
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/usr/iface.c b/usr/iface.c
index 870dba0a1fcc..940ee2388945 100644
--- a/usr/iface.c
+++ b/usr/iface.c
@@ -1002,7 +1002,8 @@ int iface_setup_from_boot_context(struct iface_rec *iface,
 			sizeof(iface-iname));
 
 	if (strlen(context-scsi_host_name)) {
-		if (sscanf(context-scsi_host_name, iscsi_boot%u, hostno) != 		1) {
+		if (sscanf(context-scsi_host_name,
+			   iscsi_boot%u, hostno) != 1) {
 			log_error(Could not parse %s's host no.,
   context-scsi_host_name);
 			return 0;
diff --git a/utils/fwparam_ibft/fw_entry.c b/utils/fwparam_ibft/fw_entry.c
index 295e905620eb..9f0797fdceb2 100644
--- a/utils/fwparam_ibft/fw_entry.c
+++ b/utils/fwparam_ibft/fw_entry.c
@@ -67,15 +67,15 @@ int fw_setup_nics(void)
 	 * to force iSCSI traffic through correct NIC
 	 */
 	list_for_each_entry(context, targets, list) {			
-	/* if it is a offload nic ignore it */
-	if (!net_get_transport_name_from_netdev(context-iface,
+		/* if it is a offload nic ignore it */
+		if (!net_get_transport_name_from_netdev(context-iface,
 			transport))
 			continue;
 
 		if (iface_prev == NULL || strcmp(context-iface, iface_prev)) {
 			/* Note: test above works because there is a
- 			 * maximum of two targets in the iBFT
- 			 */
+			 * maximum of two targets in the iBFT
+			 */
 			iface_prev = context-iface;
 			needs_bringup = 1;
 		}
diff --git a/utils/fwparam_ibft/fwparam_sysfs.c b/utils/fwparam_ibft/fwparam_sysfs.c
index 09dd9fd5cbbc..b5319063785b 100644
--- a/utils/fwparam_ibft/fwparam_sysfs.c
+++ b/utils/fwparam_ibft/fwparam_sysfs.c
@@ -325,7 +325,7 @@ static int get_boot_info(struct boot_context *context, char *rootdir,
 	nic_cnt = 0;
 	tgt_cnt = 0;
 	if (file_exist(initiator_dir)) {
-		/* Find the target's and the ethernet's */
+		/* Find the targets and the ethernets */
 		rc = nftw(rootdir, find_sysfs_dirs, 20, 1);
 
 		/* Find wihch target and which ethernet have
@@ -401,7 +401,7 @@ static int get_targets(struct list_head *list, char *rootdir, char *subsys)
 	nic_cnt = 0;
 	tgt_cnt = 0;
 
-	/* Find the target's and the ethernet's */
+	/* Find the targets and the ethernets */
 	nftw(rootdir, find_sysfs_dirs, 20, 1);
 	for (i = 0; i  tgt_cnt; i++) {
 		context = calloc(1, sizeof(*context));
-- 
2.1.2

From 6d094af5064206b36f99c338f6447293f197425e Mon Sep 17 00:00:00 2001
From: Hannes Reinecke h...@suse.de
Date: Fri, 14 Nov 2014 11:19:10 -0800
Subject: [PATCH 2/4] Represent DHCP origin as an enum, not a string.

See IBFT standard for location of origin field in iBFT table,
and see MS document: http://msdn.microsoft.com/en-us/library/aa366281.aspx
for description of enums, duplicated here in part:

	typedef enum  {
	  IpPrefixOriginOther= 0,
	  IpPrefixOriginManual,
	  IpPrefixOriginWellKnown,
	  IpPrefixOriginDhcp,
	  IpPrefixOriginRouterAdvertisement,
	  IpPrefixOriginUnchanged= 16
	} IP_PREFIX_ORIGIN;
---
 include/fw_context.h   | 11 ++-
 utils/fwparam_ibft/fw_entry.c  |  5 +++--
 utils/fwparam_ibft/fwparam_sysfs.c |  3 +--
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/include/fw_context.h b/include/fw_context.h
index 295b54d3d0c9..6a7ec1a64967 100644
--- a/include/fw_context.h
+++ b/include/fw_context.h
@@ -28,6 +28,15 @@
 #include list.h
 #include auth.h
 
+enum ibft_ip_prefix_origin {
+	IBFT_IP_PREFIX_ORIGIN_OTHER	= 0,
+	IBFT_IP_PREFIX_ORIGIN_MANUAL,
+	IBFT_IP_PREFIX_ORIGIN_WELL_KNOWN,
+	IBFT_IP_PREFIX_ORIGIN_DHCP,
+	IBFT_IP_PREFIX_ORIGIN_ROUTER_ADVERTISEMENT,
+	IBFT_IP_PREFIX_ORIGIN_UNCHANGED = 

Re: [PATCH 06/11] open-isns: Make default IQN prefix configurable

[The Lee-Man]

On Sunday, November 16, 2014 11:11:59 PM UTC-8, Uli wrote:

 Hi! 

 I don't have the full context: Why is a IQNPREFIX necessary at all? It 
 mean that there are incomplete IQNs somewhere? 


It is used to created the SourceName if not specified. This name is 
(usually) an IQN identifying the source system. If not supplied, it is 
built from this prefix and the host system name.

With the patches from Hannes, it is taken from 
/etc/iscsi/initiatorname.iscsi before being constructed (if needed).


 Regards, 
 Ulrich 

  Lee Duncan leeman...@gmail.com javascript: schrieb am 15.11.2014 
 um 02:15 in 
 Nachricht 1416014130-25502-7-git-send-email-leeman.dun...@gmail.com 
 javascript:: 
  From: Hannes Reinecke ha...@suse.de javascript: 
  
  This patch makes the default IQN prefix for iSNS configurable 
  at compile-time. 
  
  It can be modified by setting 
  'IQNFLAGS = -DIQNPREFIX=\iqn.-MM\' 
  when calling 'make'. 
  
  Signed-off-by: Hannes Reinecke ha...@suse.de javascript: 
  --- 
   utils/open-isns/Makefile.in | 3 +++ 
   utils/open-isns/message.c   | 4  
   2 files changed, 7 insertions(+) 
  
  diff --git a/utils/open-isns/Makefile.in b/utils/open-isns/Makefile.in 
  index cb721f2b990a..46d2723739d0 100644 
  --- a/utils/open-isns/Makefile.in 
  +++ b/utils/open-isns/Makefile.in 
  @@ -83,6 +83,9 @@ distclean:: 
   rm -f config.h Makefile config.status config.log 
   rm -rf autom4te.cache 

  +message.o: message.c 
  +gcc $(CFLAGS) $(CPPFLAGS) $(IQNFLAGS) -c -o $@ message.c 
  + 
   $(LIB): $(LIBOBJS) 
   ar cr $@ $(LIBOBJS) 

  diff --git a/utils/open-isns/message.c b/utils/open-isns/message.c 
  index 4cd40c3e4d3a..db67a2cc1e15 100644 
  --- a/utils/open-isns/message.c 
  +++ b/utils/open-isns/message.c 
  @@ -27,7 +27,11 @@ 
* we fake it by assigning a date before the 
* dawn of time. 
*/ 
  +#ifndef IQNPREFIX 
   #define DUMMY_IQN_PREFIXiqn.1967-12. 
  +#else 
  +#define DUMMY_IQN_PREFIX IQNPREFIX 
  +#endif 

   static uint32_tisns_xid = 1; 

  -- 
  2.1.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+...@googlegroups.com javascript:. 
  To post to this group, send email to open-...@googlegroups.com 
 javascript:. 
  Visit this group at http://groups.google.com/group/open-iscsi. 
  For more options, visit https://groups.google.com/d/optout. 






-- 
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: [PATCH 08/11] open-isns: Read source name from /etc/iscsi/initiatorname.iscsi

[The Lee-Man]

On Sunday, November 16, 2014 11:16:17 PM UTC-8, Uli wrote:

  Lee Duncan leeman...@gmail.com javascript: schrieb am 15.11.2014 
 um 02:15 in 
 Nachricht 1416014130-25502-9-git-send-email-leeman.dun...@gmail.com 
 javascript:: 
  From: Hannes Reinecke ha...@suse.de javascript: 
 [...] 
  diff --git a/utils/open-isns/config.c b/utils/open-isns/config.c 
  index 731858854650..c2cbdfbce773 100644 
  --- a/utils/open-isns/config.c 
  +++ b/utils/open-isns/config.c 
  @@ -92,6 +92,37 @@ __isns_config_defaults(void) 
   } 

   /* 
  + * Read /etc/iscsi/initiatorname.iscsi 
  + */ 

 This comment is very much confising, because `filename' is read, not 
 /etc/iscsi/initiatorname.iscsi. 


I will fix/move the comment and resubmit.
 


  +int 
  +isns_read_initiatorname(const char *filename) 
  +{ 
  +FILE*fp; 
  +char*name, *pos; 
  + 
  +if ((fp = fopen(filename, r)) == NULL) { 
  +perror(filename); 
  +return -1; 
  +} 
  + 
  +while ((pos = parser_get_next_line(fp)) != NULL) { 
  +pos[strcspn(pos, #)] = '\0'; 
  + 
  +if (!(name = parser_get_next_word(pos))) 
  +continue; 
  +if (strcmp(name, InitiatorName)) 
  +continue; 
  +if (pos[0] == '=') 
  +pos++; 
  +if (!strncmp(pos, iqn., 4)) 
  +isns_assign_string(isns_config.ic_source_name, 
 pos); 
  +} 
  + 
  +fclose(fp); 
  +return 0; 
  +} 
  + 
  +/* 
 [...] 
  diff --git a/utils/open-isns/isnsdd.c b/utils/open-isns/isnsdd.c 
  index 850060a53294..5b0dfb4c56fe 100644 
  --- a/utils/open-isns/isnsdd.c 
  +++ b/utils/open-isns/isnsdd.c 
  @@ -161,6 +161,7 @@ main(int argc, char **argv) 
   if (optind != argc) 
   usage(1, NULL); 

  +#if 0 
   /* If the config code derives the source name 
* automatically, we want it to be distinct from 
* any other source name (chosen by eg the iSCSI 
  @@ -168,11 +169,21 @@ main(int argc, char **argv) 
* somewhat lame attempt. 
*/ 
   isns_config.ic_source_suffix = isns; 
  - 
  +#endif 
   isns_read_config(opt_configfile); 

  +if (!isns_config.ic_source_name) { 
  +/* 
  + * Try to read the source name from open-iscsi 
 configuration 
  + */ 
  +isns_read_initiatorname(ISCSI_DEFAULT_INITIATORNAME); 

 You might add the comment here instead ;-) 


  +} 
  + 
  +isns_init_names(); 
  + 
   if (!isns_config.ic_source_name) 
   usage(1, Please specify an iSNS source name); 
  + 
   source = isns_source_create_iscsi(isns_config.ic_source_name); 

   isns_write_pidfile(isns_config.ic_pidfile); 
  diff --git a/utils/open-isns/paths.h b/utils/open-isns/paths.h 
  index b54612c55479..d0deabd3bfaa 100644 
  --- a/utils/open-isns/paths.h 
  +++ b/utils/open-isns/paths.h 
  @@ -19,4 +19,6 @@ 
   #define ISNS_DEFAULT_ISNSADM_CONFIGISNS_ETCDIR /isnsadm.conf 
   #define ISNS_DEFAULT_LOCAL_REGISTRYISNS_RUNDIR /isns.registry 

  +#define 
 ISCSI_DEFAULT_INITIATORNAME/etc/iscsi/initiatorname.iscsi 
  + 
   #endif /* ISNS_CONFIG_H */ 
  -- 
  2.1.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+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: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Tuesday, November 18, 2014 10:55:31 PM UTC-8, Uli wrote:

  Lee Duncan leeman...@gmail.com javascript: schrieb am 18.11.2014 
 um 22:35 in 
 Nachricht 1416346536-18198-1-git-seemail-###-duncan@ javascript:###: 
  The following patch fixes a problem where the CPU becomes compute bound 
  when rediscovering targets, when there are hundreds of sessions. 
  
  When his occurs, most of the time is spent in the function 
  iscsi_sysfs_for_each_session(). This function does a scandir(), 
  sorted alphabetically, to get a list of sessions, then scans 
  that list looking for a match. When there are hundreds of sesions 
  this can take forever. 


 I wonder: What takes forever: reading hundreds of sysfs entries, sorting 
 them, or looking for a match? I guess none of them should take forever 
 unless the algorithm is really very bad. 


The problem is not the sort, since the patch still does a sort of the 
directory entries.

I believe the problem is in processing the sorted data, in 
iscsi_sysfs_for_each_session(). This function does dozens or more 
open/read/close cycles on sysfs attributes. Multiply that times hundreds of 
session, and you have tens of thousands I/O operations. This fix ensures 
that, much of time, this loop is only gone through once.


  
  This patch saves the current session and then ensures that this 
  session sorted to the front of the list. Testing shows that 
  CPU usage goes from near 100% to near 0% when running cable 
  plug tests with hundreds of sessions. 
  
  Signed-off-by: Lee Duncan leeman...@gmail.com javascript: 
  
  -- 
  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+...@googlegroups.com javascript:. 
  To post to this group, send email to open-...@googlegroups.com 
 javascript:. 
  Visit this group at http://groups.google.com/group/open-iscsi. 
  For more options, visit https://groups.google.com/d/optout. 






-- 
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: Re: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Wednesday, November 19, 2014 11:23:10 PM UTC-8, Uli wrote:

  The Lee-Man leeman...@gmail.com javascript: schrieb am 19.11.2014 
 um 19:35 in 
 Nachricht 16860f30-b55c-4106-a4e1-d7badfc36...@googlegroups.com 
 javascript:: 
  On Tuesday, November 18, 2014 10:55:31 PM UTC-8, Uli wrote: 
  
   Lee Duncan leeman...@gmail.com javascript: schrieb am 
 18.11.2014 
  um 22:35 in 
  Nachricht 1416346536-18198-1-git-seemail-###-duncan@ 
 javascript:###: 
   The following patch fixes a problem where the CPU becomes compute 
 bound 
   when rediscovering targets, when there are hundreds of sessions. 
   
   When his occurs, most of the time is spent in the function 
   iscsi_sysfs_for_each_session(). This function does a scandir(), 
   sorted alphabetically, to get a list of sessions, then scans 
   that list looking for a match. When there are hundreds of sesions 
   this can take forever. 
  
  
  I wonder: What takes forever: reading hundreds of sysfs entries, 
 sorting 
  them, or looking for a match? I guess none of them should take forever 
  unless the algorithm is really very bad. 
  
  
  The problem is not the sort, since the patch still does a sort of the 
  directory entries. 
  
  I believe the problem is in processing the sorted data, in 
  iscsi_sysfs_for_each_session(). This function does dozens or more 
  open/read/close cycles on sysfs attributes. Multiply that times hundreds 
 of 
  session, and you have tens of thousands I/O operations. This fix ensures 
  that, much of time, this loop is only gone through once. 

 When the reason for the sort is just to find some extrema (min or max), 
 the sort is not needed.


Actually, in general, that is not true. In the case where we've cached an 
entry, that may or may
not be true, depending on the use case.
 

 Also when just needing some extreme entry (min or max) it makes little 
 sense to populate some array with all entries just to discard them all, but 
 one. I don't know the details, but if all the other stuff isn't needed, it 
 shouldn't be read.


It also does not hurt anything to sort the whole array. I am trying to fix 
an issue where the CPU become completely compute-bound with hundreds (or 
more) sessions coming and going.

It sounds to me like you would like to redesign some of the code to make it 
more efficient. While I believe in efficiency in general, I don't believe 
the trade-off is worth the time here, since this is not the issue that is 
causing problems.


 What I saw from your path is that you just cheat on the sort routine. So 
 if getting the entries takes all the time (I guess it happens before 
 sorting), I don't see how you save a lot of time that way, _unless_ the 
 compare routine actually does I/O to compare the values which is bad, 
 because every value is compared more than once in a typical sort. 


As I said, it is trying to populate hundreds of internal session objects to 
find the one we need that takes so much time.

I believe part of the problem making more optimizations here is the fact 
that iscsi_sysfs_for_each_session() is called with a compare function 
pointer, so the routine does not know if the first entry in the sort list 
is going to make the caller happy or not. So in order to make this code 
work in all current cases *and* fix the compute-bound problem, a small 
change that sorts the last-known session to the top of the list cannot 
break any code, and also solves my problem.

Here are some actual numbers from testing this patch:

For an idle system (no data or link bounce) with 120 targets the CPU time 
improvement is about 3:1 after running 72 hours

For a system with data and link bounce every 10 minutes the CPU time 
improvement is on the order to 100:1 after 24 hours.  
The CPU time with the patch is linear with time.  Without the patch, it's 
exponential and will break the system to its knees after 1 day of bouncing 
links.  
Memory use was over 40G additional on the system without the patch.

Here's sar data from the 2 systems (bumble1 has the patch; bumble2 does 
not).  This is with bouncing links after 24+ hours:

bumble1:~ # sar -u 1 1000
Linux 2.6.32.54-0.23.TDC.1.R.2-default (bumble1)11/13/14   
 _x86_64_

10:52:16CPU %user %nice   %system   %iowait%steal 
%idle
10:52:17all  0.00  0.00  0.02  0.00  0.00 
99.98
10:52:18all  0.00  0.00  0.07  0.00  0.00 
99.93
10:52:19all  0.00  0.00  0.04  0.00  0.00 
99.96
10:52:20all  0.00  0.00  0.16  0.00  0.00 
99.84
10:52:21all  0.00  0.00  0.04  0.00  0.00 
99.96
10:52:22all  0.00  0.00  0.10  0.00  0.00 
99.90
10:52:23all  0.05  0.00  0.07  0.00  0.00 
99.89


bumble2:~ # sar -u 1 1
Linux 2.6.32.54-0.23.TDC.1.R.2-default (bumble2)11/13/14   
 _x86_64_

10:52:20CPU

Re: Re: Re: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Friday, November 21, 2014 12:37:59 AM UTC-8, Uli wrote:

  The Lee-Man leeman...@gmail.com javascript: schrieb am 20.11.2014 
 um 18:07 in 
 Nachricht dc3f5a91-d2a1-41e1-bc93-e5d9f44ba...@googlegroups.com 
 javascript:: 
  On Wednesday, November 19, 2014 11:23:10 PM UTC-8, Uli wrote: 
  
   The Lee-Man leeman...@gmail.com javascript: schrieb am 
 19.11.2014 
  um 19:35 in 
  Nachricht 16860f30-b55c-4106-a4e1-d7badfc36...@googlegroups.com 
 javascript: 
  javascript:: 
   On Tuesday, November 18, 2014 10:55:31 PM UTC-8, Uli wrote: 
   
Lee Duncan leeman...@gmail.com javascript: schrieb am 
  18.11.2014 
   um 22:35 in 
   Nachricht 1416346536-18198-1-git-seemail-###-duncan@ 
  javascript:###: 
The following patch fixes a problem where the CPU becomes compute 
  bound 
when rediscovering targets, when there are hundreds of sessions. 

When his occurs, most of the time is spent in the function 
iscsi_sysfs_for_each_session(). This function does a scandir(), 
sorted alphabetically, to get a list of sessions, then scans 
that list looking for a match. When there are hundreds of sesions 
this can take forever. 
   
   
   I wonder: What takes forever: reading hundreds of sysfs entries, 
  sorting 
   them, or looking for a match? I guess none of them should take 
 forever 
   unless the algorithm is really very bad. 
   
   
   The problem is not the sort, since the patch still does a sort of the 
   directory entries. 
   
   I believe the problem is in processing the sorted data, in 
   iscsi_sysfs_for_each_session(). This function does dozens or more 
   open/read/close cycles on sysfs attributes. Multiply that times 
 hundreds 
  of 
   session, and you have tens of thousands I/O operations. This fix 
 ensures 
   that, much of time, this loop is only gone through once. 
  
  When the reason for the sort is just to find some extrema (min or max), 
  the sort is not needed. 
  
  
  Actually, in general, that is not true. In the case where we've cached 
 an 
  entry, that may or may 
  not be true, depending on the use case. 

 What I was saying: If you just need to remember one entry from a list of 
 entries, there is no need to move entries around (as sorting does). 


I continue to understand what you are saying.

What I am trying to say, and evidently not doing very well,
is that the function where this change was made does not know what
sessions the caller wants. This is because this function is called
in different ways.

One of the ways this function is called is the find the current
session. But, again, the function that gets and sorts sessions
doesn't know this. This function is generic, in that only:

1. gets a list of sessions
2. Sorts them (usually alphabetically, though I believe
that's arbitrary), and
3. then scans the sessions, one at a time, filling in
   lots of attributes for each one, before seeing the
   the calling function wants this session or not

It's true that this does not seem efficient for the case where
we are just looking for the current session. But my contention
is that it is efficient enough, for the time being.

Could this whole section of code be redesigned? Yes, of course,
and I'm fairly sure it could be made faster. But that would take
a redesign of the places where these search functions are called,
not just the search function itself.



  
  Also when just needing some extreme entry (min or max) it makes little 
  sense to populate some array with all entries just to discard them all, 
 but 
  one. I don't know the details, but if all the other stuff isn't needed, 
 it 
  shouldn't be read. 
  
  
  It also does not hurt anything to sort the whole array. I am trying to 
 fix 
  an issue where the CPU become completely compute-bound with hundreds (or 
  more) sessions coming and going. 

 And I tried to understand why it's going to be CPU-bound, and how you came 
 up with your fix.


It becomes CPU bound from all slow I/O it's doing. Disc I/O is fast, 
but reads (e.e.g from /sys) are relatively slow. And when you have
more reads to do then time to do them (i.e. with new requests coming in),
things get backed up and the CPU can't keep up.


  
  It sounds to me like you would like to redesign some of the code to make 
 it 
  more efficient. While I believe in efficiency in general, I don't 
 believe 
  the trade-off is worth the time here, since this is not the issue that 
 is 
  causing problems. 

 I understand, but one quick and dirty fix, then another, and one more, and 
 at some time later you have a real mess. Redesigning code, especially if 
 the existing one shows to have issues, is quite normal to do (even though 
 not popular). 


I don't consider this a quick nor dirty fix, but perhaps I'm being picky 
about language.

My point is that this is a simple optimization.

And I did not come up with it. It came from a large SUSE customer.

I do not have the network nor the number of targets to be able
to perform

Re: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Friday, November 21, 2014 8:06:55 PM UTC-8, Mike Christie wrote:

On Nov 18, 2014, at 3:35 PM, Lee Duncan leeman...@gmail.com javascript: 
wrote: 

 The following patch fixes a problem where the CPU becomes compute bound 
 when rediscovering targets, when there are hundreds of sessions. 
 
 When his occurs, most of the time is spent in the function 
 iscsi_sysfs_for_each_session(). This function does a scandir(), 
 sorted alphabetically, to get a list of sessions, then scans 
 that list looking for a match. When there are hundreds of sesions 
 this can take forever. 
 
 This patch saves the current session and then ensures that this 
 session sorted to the front of the list. Testing shows that 
 CPU usage goes from near 100% to near 0% when running cable 
 plug tests with hundreds of sessions. 

When/how is iscsi_sysfs_for_each_session getting run during this test? 

Is it iscsid during its relogin/eh handling or something else like a script 
running iscsiadm commands? 



The CPU-bound problem occurs when running a disconnect test.
With over a hundred sessions cables are randomly unplugged and
plugged back in. So it is relogin/eh handling.


Here is a stack track from interrupting the daemon when it's CPU-bound.
(Apologies for the wrap):


(gdb) where
#0 0x7fb795d6fb76 in strcmp () from /lib64/libc.so.6
#1 0x0041c173 in sysfs_attr_get_value (devpath=value optimized 
out, attr_name=value optimized out) at sysfs.c:378
#2 0x0041c4cd in sysfs_get_value (id=0x7fff524e0ae0 host88, 
subsys=0x454452 iscsi_host, param=0x4543da port_state) at sysfs.c:562
#3 0x0041c661 in sysfs_get_str (id=0x1145fc20 
/class/iscsi_host/host12956/netdev, subsys=0x7fff524e0514 
/class/iscsi_host/host88/port_state, param=0x2f Address 0x2f out of 
bounds,
value=0x0, value_size=-4) at sysfs.c:613
#4 0x0042049a in iscsi_sysfs_read_iface (iface=0x17301dc0, 
host_no=88, session=0x9593233 session79, iface_kern_id=0x0) at 
iscsi_sysfs.c:769
#5 0x00421e3a in iscsi_sysfs_get_sessioninfo_by_id 
(info=0x17301db0, session=0x9593233 session79) at iscsi_sysfs.c:1154
#6 0x0042207a in iscsi_sysfs_for_each_session (data=0x16a8e120, 
nr_found=0x7fff524e0e44, fn=0x4042f0 iscsi_match_session) at 
iscsi_sysfs.c:1185
#7 0x0043569b in iscsi_check_for_running_session (rec=0x1145fc20) 
at session_mgmt.c:469
#8 0x00436726 in update_sessions (new_rec_list=0x7fff524e0ef0, 
targetname=0x0, iname=0x2f Address 0x2f out of bounds) at discoveryd.c:176
#9 0x00436b54 in __do_st_disc_and_login (drec=value optimized 
out) at discoveryd.c:1051
#10 do_st_disc_and_login (drec=value optimized out) at discoveryd.c:1067
#11 0x00436100 in fork_disc (def_iname=0x0, drec=0x7fff524e0f90, 
poll_inval=30, do_disc_and_login=0x436a30 do_st_disc_and_login) at 
discoveryd.c:210
#12 0x004361d5 in st_start (data=value optimized out, 
drec=0x7fff524e0f90) at discoveryd.c:1082
#13 0x0041b6b8 in idbm_for_each_drec (type=0, config_root=value 
optimized out, data=0x0, fn=0x436180 st_start) at idbm.c:1388
#14 0x00435171 in main (argc=value optimized out, argv=value 
optimized out) at iscsid.c:524

Looked over the code a bit more since I had some time, and it looks like 
this is
one of the two places where the code calls iscsi_sysfs_for_each_session()
when it's really just looking for one session.

And it does this by:

- getting a list of all sessions (sorted, which isn't
  needed but doesn't seem to hurt). They seem
  to be sorted in alphabetical session-ID order

- for each entry, populate it's sysfs properties, then
  see if this session matches 4 key values:

  - session ID should match (numerical compare)
  - target name should match (string compare)
  - iSCSI address should match (string + number)
  - port no should match (numerical), and
  - interface should match (string x2)

These tests are done in short-circuit fashion, so if the
session ID does not match, then the other tests
are not done, even though we retrieved all the
/sysfs data.

And in our problem case, we have a  particular session
ID we are looking for. But that session could easily be
sorted at the back of the list (before my patch),
if it's a newer session. And that would make *lots* of
/sysfs IOs that were not needed.

The reason the submitted fix works is that I work around
this unneeded gathering of /sysfs data by sorting the
session we care about to the front of the list.

Another perhaps cleaner re-write would be to
create a new function that can search efficiently for
a session by session ID, not gathering the other
/sysfs data until needed, i.e. if and only if the
session matches. We know that session
IDs are unique, so it could search the session list
and return just the one session we are looking for,
or FAILURE if it cannot be found.

I will work on a patch -- it's starting to sound
interesting to me.  :)

[Apologies for smiley faces -- too much time on FB.]

-- 
You received this message because you are 

Re: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

Okay, I spent most the day yesterday playing with the
code in question, i.e. the open-iscsi code that rescans
the session list looking for the current session.

In particular, I was looking at update_sessions().

One thing I noticed is that this code only gets executed
if discovery.sendtargets.use_discoveryd is set to Yes for
a particular target, by the way.

Bottom line: I did not find any way to significantly speed
up the search other than the cache the last session
patch I already posted.

Here's the problem: the submitted patch makes this
particular use case O(1). You can't get much faster
than that, i.e. it takes a fixed time no matter how
many sessions are present.

The only patches I can come up with make that
search take O(n). That's because the only
way other than caching to find the last session
used is to search through the session list.

Are there optimization that could be done in this code?
Yes, of course. It hasn't been touched in a while, is
not usually in the critical path, and generally works,
so nobody messes with it much.

But I believe those optimizations are unwarranted
given the fact that they are in the noise compared
to sysfs read delays I have seen.

So my previous patch submission stands.

Mike: what are your thoughts? Users that
have many many sessions need this. I'm open
to alternative solutions, I just don't see any.

Bottom line: there is no simple way to find a
particular open-iscsi session from /sysfs without
reading and comparing several strings, so any
fix that reduces the time per entry will still leave
the search at O(n). The solution has to be a
way to make this time fixed, not linear, as
the submitted patch does.

-- 
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: Re: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Monday, November 24, 2014 11:42:31 PM UTC-8, Uli wrote:

  The Lee-Man leeman...@gmail.com javascript: schrieb am 24.11.2014 
 um 18:04 in 
 Nachricht dfb5172f-05e8-4027-867e-8e2b1969f...@googlegroups.com 
 javascript:: 
 [...] 
  Here's the problem: the submitted patch makes this 
  particular use case O(1). You can't get much faster 

 Are you sure? You modified the compare function used by sort. Even if the 
 list is sorted before you add a new entry at the end, more tan one call to 
 the compare function is performed (unless I miss the obvious). Typically 
 the best you can get is like O(log2(n)) (for binary search) 


Yes. As I said, the sort is a non-issue, based on (1) the small amount of 
time it takes to sort a list, which is swamped by the amount of time it 
takes to do /sysfs I/O. So even though the search *does* (as you say) take 
longer than O(1), it never killed the CPU. 


  than that, i.e. it takes a fixed time no matter how 
  many sessions are present. 
  
  The only patches I can come up with make that 
  search take O(n). That's because the only 

 If you search for the extreme value of an unsorted list with n elements, 
 you can't beat that. That's why you (build and) sort the list if it's 
 intended to be searched more than once, I guess. 


Yes, I can beat that, and the patch does just that. O(1) is better than 
O(n).

When I tried to improve the patch that kept being the bottom line. No 
matter how much I optimize a search of the list, it's still going to have 
to search half the list (linearly), on average, before it finds the session 
being searched for. 


  way other than caching to find the last session 
  used is to search through the session list. 
  
 [...] 




-- 
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: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Tuesday, November 25, 2014 9:42:59 AM UTC-8, Mike Christie wrote:

 On 11/24/2014 11:04 AM, The Lee-Man wrote: 
  Okay, I spent most the day yesterday playing with the 
  code in question, i.e. the open-iscsi code that rescans 
  the session list looking for the current session. 
  
  In particular, I was looking at update_sessions(). 
  
  One thing I noticed is that this code only gets executed 
  if discovery.sendtargets.use_discoveryd is set to Yes for 
  a particular target, by the way. 

 So how does your interconnect test come into play for this issue? It 
 seems like you should be hitting this issue all the time even when the 
 connection is ok, because that code polls every N seconds.


When the connections are being dropped and then reconnected, the
sessions (created by the kernel) are coming and going. And each time
a connection goes away and comes back, it gets a new session ID,
and a new symlink in /sys/class/iscsi_sessions, which of course
is not cached. (This is my theory, since I don't have a configuration
which can test this ATM.)

This is backed up by the fact that I see lot of messages like:

Oct 13 13:00:09 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:09 bumble1 iscsid: could not find session info for session11
Oct 13 13:00:09 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:09 bumble1 iscsid: could not find session info for session11
Oct 13 13:00:10 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:10 bumble1 iscsid: could not find session info for session5
Oct 13 13:00:10 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:10 bumble1 iscsid: could not find session info for session5
Oct 13 13:00:10 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:10 bumble1 iscsid: could not find session info for session10
Oct 13 13:00:11 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:11 bumble1 iscsid: could not find session info for session11
Oct 13 13:00:12 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:12 bumble1 iscsid: could not find session info for session11
Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:13 bumble1 iscsid: could not find session info for session13
Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:13 bumble1 iscsid: could not find session info for session17
Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:13 bumble1 iscsid: could not find session info for session14
Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:13 bumble1 iscsid: could not find session info for session18
Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:13 bumble1 iscsid: could not find session info for session15
Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:13 bumble1 iscsid: could not find session info for session16
Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:13 bumble1 iscsid: could not find session info for session19
Oct 13 13:00:14 bumble1 iscsid: could not read session targetname: 5
Oct 13 13:00:14 bumble1 iscsid: could not find session info for session20

So not only are we doing I/O to discover info about new sessions, but
existing sessions are going away, causing lots of error I/O output, again
swamping the time taken to compute things.


 
  Bottom line: I did not find any way to significantly speed 
  up the search other than the cache the last session 
  patch I already posted. 

 Can you explain the problem again? I thought originally you were 
 thinking it was due to the sysfs operations taking too long and then 
 compounded by them being repeated. However, I thought for the discoveryd 
 daemon process, sysfs.c is caching that info, so we are not actually 
 reading from sysfs every time. 

 Is the issue just a normal old bad search cpu time type of issue and not 
 really sysfs read/scan operations taking a long time? If so, then the 
 patch makes sense. 


I know sysfs attributes are cached here, after spending a day playing
with the code. And, as I said, I'm guessing as to the /sysfs read delays
part, since I can't recreate the problem. But I'm sure it is not the sort
causing the delay, since the supplied patch fixed the problem, and the
sort is still present.

Think about it: sorting one or two hundred entries is not going to take
very long compared to reading a dozen attributes for the new sessions
since the last discoveryd scan.

It seems to me like the problem should be related to the discoveryd
poll time: if that poll time is less than the time it takes to rescan
sessions, then things will back up. So even if we didn't have
a problem, for example, with the default rescan time of 30 seconds,
what happens if we set the poll time to 10 or 5 seconds?

In simple terms, this patch just caches the last session, and
sorts it to the front

Re: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Tuesday, November 25, 2014 2:00:22 PM UTC-8, Mike Christie wrote:

 On 11/25/2014 12:49 PM, The Lee-Man wrote: 
  On Tuesday, November 25, 2014 9:42:59 AM UTC-8, Mike Christie wrote: 
  
  On 11/24/2014 11:04 AM, The Lee-Man wrote: 
   Okay, I spent most the day yesterday playing with the 
   code in question, i.e. the open-iscsi code that rescans 
   the session list looking for the current session. 
   
   In particular, I was looking at update_sessions(). 
   
   One thing I noticed is that this code only gets executed 
   if discovery.sendtargets.use_discoveryd is set to Yes for 
   a particular target, by the way. 
  
  So how does your interconnect test come into play for this issue? It 
  seems like you should be hitting this issue all the time even when 
 the 
  connection is ok, because that code polls every N seconds. 
  
  
  When the connections are being dropped and then reconnected, the 
  sessions (created by the kernel) are coming and going. And each time 
  a connection goes away and comes back, it gets a new session ID, 
  and a new symlink in /sys/class/iscsi_sessions, which of course 
  is not cached. (This is my theory, since I don't have a configuration 
  which can test this ATM.) 

 The session and/or connection id does not change if the connection is 
 just dropped and then relogged into by iscsid. It would only change if 
 you are removing a session by hand by doing iscsiadm ... --logout, then 
 readding it by doing iscsiadm  --login, or if maybe discoveryd is 
 causing sessions to be deleted then added due to getting different 
 portals back or due to a bug in that code. 

 Or, are you using eql's multipating software that might be dynamically 
 creating/deleting sessions? 


Not using eql multipathing (I don't believe).

When I stop iscsid and restart it, I get a new session ID.

I have not learned the code enough to answer this question, so I'll ask 
you, to make sure.

Is there nothing else that changes the session ID?

The current code in update_sessions() passes in zero for the session ID, 
which means match any session ID. 



  
  This is backed up by the fact that I see lot of messages like: 
  

 Maybe you should send the entire log. 


I do not have it, though I have requested it. 


  Oct 13 13:00:09 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:09 bumble1 iscsid: could not find session info for 
 session11 
  Oct 13 13:00:09 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:09 bumble1 iscsid: could not find session info for 
 session11 
  Oct 13 13:00:10 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:10 bumble1 iscsid: could not find session info for session5 
  Oct 13 13:00:10 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:10 bumble1 iscsid: could not find session info for session5 
  Oct 13 13:00:10 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:10 bumble1 iscsid: could not find session info for 
 session10 
  Oct 13 13:00:11 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:11 bumble1 iscsid: could not find session info for 
 session11 
  Oct 13 13:00:12 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:12 bumble1 iscsid: could not find session info for 
 session11 
  Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:13 bumble1 iscsid: could not find session info for 
 session13 
  Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:13 bumble1 iscsid: could not find session info for 
 session17 
  Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:13 bumble1 iscsid: could not find session info for 
 session14 
  Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:13 bumble1 iscsid: could not find session info for 
 session18 
  Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:13 bumble1 iscsid: could not find session info for 
 session15 
  Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:13 bumble1 iscsid: could not find session info for 
 session16 
  Oct 13 13:00:13 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:13 bumble1 iscsid: could not find session info for 
 session19 
  Oct 13 13:00:14 bumble1 iscsid: could not read session targetname: 5 
  Oct 13 13:00:14 bumble1 iscsid: could not find session info for 
 session20 
  
  So not only are we doing I/O to discover info about new sessions, but 
  existing sessions are going away, causing lots of error I/O output, 
 again 
  swamping the time taken to compute things. 
  
  
   
   Bottom line: I did not find any way to significantly speed 
   up the search other than the cache the last session 
   patch I already posted. 
  
  Can you explain the problem again? I

Current Portal vs Persistent Portal Question

[The Lee-Man]

Hi Mike:

I am dealing with a problem in Equallogic, and it looks like the Current 
Portal and Persistent Portal are different.

As this is something I haven't seen before, I was hoping you could explain 
what it is.

I see in the README:

...
Current Portal: portal currently logged into
Persistent Portal: portal we would fall back to if we had got 
redirected during login

Is this related to Equallogic's iSCSI login redirect?

It sounds like the Persistent Portal is the one that we initially try to 
log into, and the Current Portal is the one we get redirected to. Or is 
that backwards?

What happens if we discover the main (group virtual) portal, and our Node 
record reflects that, then we get redirected? It seems like the Portal is 
going to differ between the Node record and the Session record, which might 
explain what I'm seeing.

In this particular case, the problem occurs when Yast tries to step through 
the Session records, doing an iscsiadm -m node -I default -T iqn -p 
ip:port -P1 for each session, but IPs does not match.

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+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: [PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

[The Lee-Man]

On Wednesday, November 26, 2014 1:11:46 PM UTC-8, Mike Christie wrote:

 On 11/25/2014 05:15 PM, The Lee-Man wrote: 
  On Tuesday, November 25, 2014 2:00:22 PM UTC-8, Mike Christie wrote: 
  
  On 11/25/2014 12:49 PM, The Lee-Man wrote: 
   On Tuesday, November 25, 2014 9:42:59 AM UTC-8, Mike Christie 
 wrote: 
   
   On 11/24/2014 11:04 AM, The Lee-Man wrote: 
Okay, I spent most the day yesterday playing with the 
code in question, i.e. the open-iscsi code that rescans 
the session list looking for the current session. 

In particular, I was looking at update_sessions(). 

One thing I noticed is that this code only gets executed 
if discovery.sendtargets.use_discoveryd is set to Yes for 
a particular target, by the way. 
   
   So how does your interconnect test come into play for this 
  issue? It 
   seems like you should be hitting this issue all the time even 
  when the 
   connection is ok, because that code polls every N seconds. 
   
   
   When the connections are being dropped and then reconnected, the 
   sessions (created by the kernel) are coming and going. And each 
 time 
   a connection goes away and comes back, it gets a new session ID, 
   and a new symlink in /sys/class/iscsi_sessions, which of course 
   is not cached. (This is my theory, since I don't have a 
 configuration 
   which can test this ATM.) 
  
  The session and/or connection id does not change if the connection 
 is 
  just dropped and then relogged into by iscsid. It would only change 
 if 
  you are removing a session by hand by doing iscsiadm ... --logout, 
 then 
  readding it by doing iscsiadm  --login, or if maybe discoveryd 
 is 
  causing sessions to be deleted then added due to getting different 
  portals back or due to a bug in that code. 
  
  Or, are you using eql's multipating software that might be 
 dynamically 
  creating/deleting sessions? 
  
  
  Not using eql multipathing (I don't believe). 
  
  When I stop iscsid and restart it, I get a new session ID. 
  

 Any time a session is removed from the kernel then readded it can change. 


So if a connection was removed, so that all of the sessions on that 
connection
go into error handling, will they not be removed eventually, if retries do 
not work?
 


 How do you start and stop it? Are you just killing the daemon by doing a 
 sigkill and restarting it by running /sbin/iscsid? If so, it should not 
 change. 


For my testing, on SLES 12, I was using sytsemctl (systemd) to start/stop 
iscsi.
I also was using discoveryd.
 


 When you kill iscsid are you also removing the sessions then on restart 
 are you creating them again? If so, then yeah the session id will change 
 because you are removing the session like is done when you do --logout. 
 Maybe you are using some init/systemd type of script? 


Yes. Again, this was just for my testing. The original testing done by a
large hardware manufacturer instead just pulled cables.

But it looks like update_sessions() logs out of stale sessions.
 



  I have not learned the code enough to answer this question, so I'll ask 
  you, to make sure. 
  
  Is there nothing else that changes the session ID? 

 Just a complete removal from the kernel like is done when the --logout 
 command is run manually or when discoveryd does it. Look at 
 iscsi_add_session() in drivers/scsi/scsi_transport_iscsi.c for when it 
 gets set. It then never changes. 

 In older versions iscsid could also remove a session if during login we 
 got a response that indicated the target was no longer there. We stopped 
 doing that though.


Original problem occurred on SLE 11 SP3, which is based on 2.0.873,
with SUSE patches.
 



 Also, I do not know what the init scripts or systemd or network manager 
 does in suse, so I have no idea if there are cases where you might be 
 deleting sessions then readding them. I have seen some distros delete 
 sessions when the network goes down, then login again when the network 
 comes back up. For these cases though, they run the iscsiadm 
 logout/login commands. 


Yes, again, in my testing only I was logging out of sessions, stopping 
iscsid,
then starting iscsid and re-logging in. But original problem did not do 
this.
 



  
  The current code in update_sessions() passes in zero for the session ID, 
  which means match any session ID. 

 I did not understand this comment wrt session ids changing. 


My comment was directed at the fact that the search for a matching
session cannot be done in O(1) without caching.

If the code passed in a session ID when searching for a matching
session, it could simply look it up via 
/sys/class/iscsi_sessions/sessionN.

But since the code passes in a wild card value, the search code
specifically ignored session ID and matches

Re: Current Portal vs Persistent Portal Question

[The Lee-Man]

On Wednesday, November 26, 2014 1:31:30 PM UTC-8, Mike Christie wrote:

 On 11/25/2014 06:58 PM, The Lee-Man wrote: 
  Hi Mike: 
  
  I am dealing with a problem in Equallogic, and it looks like the Current 
  Portal and Persistent Portal are different. 
  
  As this is something I haven't seen before, I was hoping you could 
  explain what it is. 
  
  I see in the README: 
  
  ... 
  Current Portal: portal currently logged into 
  Persistent Portal: portal we would fall back to if we had got 
  redirected during login 
  
  Is this related to Equallogic's iSCSI login redirect? 

 Yes. 

  
  It sounds like the Persistent Portal is the one that we initially try to 
  log into, and the Current Portal is the one we get redirected to. Or is 

 Correct. Persistent portal is the one returned by the discovery command. 


Excellent. I guessed correctly. :)
 


  that backwards? 
  
  What happens if we discover the main (group virtual) portal, and our 
  Node record reflects that, then we get redirected? It seems like the 

 Node record portal ip is the ip that the EQL box returns when you do 
 discovery, and it is the persistent ip value you see in sysfs and when 
 you run iscsiadm -m session. 

 Note that if a driver does not support persistent_address attr then the 
 persistent and current are both the currently logged into address. I 
 think just older qlogic driver did not export this, but does now. 

 Also, really old iser drivers did not export the non persistent address 
 so they were both the same, but that was a long time ago. 


I noticed the code that filled in both current and persistent portal, as
needed.
 


  Portal is going to differ between the Node record and the Session 
  record, which might explain what I'm seeing. 

 It should match. 


No. If the current and persistent portals differ, then only one
of them can match the current session.
 


 Run 
 iscsiadm -m session 
 and 
 iscsiadm -m session -P 1 
 and 
 iscsiadm -m node  your target/portal 

 Does it show what it should? 

  
  In this particular case, the problem occurs when Yast tries to step 
  through the Session records, doing an iscsiadm -m node -I default -T 
  iqn -p ip:port -P1 for each session, but IPs does not match. 
  

 I am not sure what you mean. The iscsiadm -m node command above prints 
 out the node record. What do you mean by session record? What gets 
 printed when you do iscsiadm -m session/iscsiadm -m session -P $N? 

 The iscsiadm -m session command prints the persistent address. See 
 session_info_print_flat, so it should match what you see in iscsiadm -m 
 node commands. 

 Maybe you could cut and paste an example of what you mean it would help. 


I do not have a Equallogic system, so I cannot do that.

Let me try to explain again. I have a bad habit of getting the information I
need but not explaining why I need it very well.

We had a Yast script that was trying to match sessions and nodes. And in
the case of an Eql array with iSCSI login redirect, the persistent and
current portals differed. The script, in error, was trying to match the
current portal to the node record, but that script should have instead
been matching the persistent portal to the node record.

I explained to them how the portal redirect works, and the script
is fixed now.

Thanks for your help! 

-- 
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: new comer questions on tgt,lio-utils and iscsitarget

[The Lee-Man]

On Tuesday, December 2, 2014 6:59:02 PM UTC-8, pilla...@gmail.com wrote:

 hi
 I am new to iscsi ,have some questions in learning,quite appreciate for 
 your help and time


This really isn't the place to ask about iSCSI targets, by the way. This 
list is for discussion of the open-iscsi iSCSI initiator package.

But I'll try to answer your questions.
 


 1 \ both lio-utils and tgt are pure user space program? Both of them are 
 using the kernel iscsi module ? So ,what is the difference between them?


No, I believe the tgt (or stgt) package uses a user-space daemon, but it 
only handles administration of connections. The transport is handled by the 
kernel. See http://stgt.sourceforge.net

The lio-utils package is being deprecated in favor of the targetcli 
package. Right now, targetcli works on top of lio-utils, but soon it will 
run standalone. See http://linux-iscsi.org/wiki/Lio-utils

The lio-utils/targetcli combo is configured in user space, but managed in 
kernel space. There is no user-space daemon running in this case.

Difference between them: plenty. Configured differently, different designs, 
and the Linux community has chosen targetcli moving forward. I have *not* 
benchmarked them, so I have no idea if one performs better than the other. 
Also, targetcli doesn't yet have every feature that tgt has, such as iSNS 
support, but targetcli is being actively developed/improved.

2 \ Are there any guide documents on how to setup a iscsi target using both 
 tgt and lio-utils?


I have created some simple example documents, but they are SUSE-based. I 
haven't published them yet, but was thinking of setting up some place where 
I could do that. I could probably email them to you if you thought they 
might be useful.

Note: if you use targetcli, try the manual page, as it has enough 
information to set up a simple target.
 


 Thanks a lot for your help and time !



-- 
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: new comer questions on tgt,lio-utils and iscsitarget

[The Lee-Man]

On Friday, December 5, 2014 11:42:12 AM UTC-8, Andy Grover wrote:

 On 12/04/2014 01:13 PM, The Lee-Man wrote: 
  On Tuesday, December 2, 2014 6:59:02 PM UTC-8, pilla...@gmail.com 
 wrote: 
  1 \ both lio-utils and tgt are pure user space program? Both of them 
  are using the kernel iscsi module ? So ,what is the difference 
  between them? 
  
  No, I believe the tgt (or stgt) package uses a user-space daemon, but 
  it only handles administration of connections. The transport is handled 
  by the kernel. See http://stgt.sourceforge.net 

 Actually the website is a little out of date. stgt moved to entirely 
 userspace, around 2011. 

 -- Andy 


Interesting. The version on SUSE still uses tgtd. :-/

I suppose I could update it, but I spend most of my time on 
lio-utils/targetcli/targte-isns these days. 

-- 
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: CentOS7 and systemd ordering when shutting down results in unclean unmount

[The Lee-Man]

I'm not familiar with CentOS. Does you iscsi-utils package have any systemd 
unit files, i.e. is the version of open-iscsi you are using integrated with 
systemd?

On Tuesday, December 9, 2014 7:28:52 AM UTC-8, awidde...@hotmail.com wrote:

 Setup iSCSI on CentOS7. Mounted a iSCSI disk and am running a small MySQL 
 instance on the disk. The iSCSI disk and MySQL instance all come online 
 fine with booting but when shutting down things seem to get very upset and 
 the drive does not get unmounted cleanly.

 Does not look like I'm the only one having the issue. Another report that 
 is very similar was posted here:

 https://www.centos.org/forums/viewtopic.php?f=47t=49337

 This might be a systemd issue but figured I'd post here first to see if 
 anyone else has had this issue and has any suggestions.

 Relevant version info:

 CentOS Linux release 7.0.1406 (Core)
 systemd-208-11.el7_0.4.x86_64
 iscsi-initiator-utils-6.2.0.873-21.el7.x86_64

 Systemd unit file for MySQL server:

 [Unit]
 Description=MySQL Server
 After=nss-lookup.target network.target remote-fs.target time-sync.target
 Wants=nss-lookup.target network.target remote-fs.target time-sync.target

 Logs from journalctl:

 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): 
 __ext4_get_inode_loc:4039: inode #58989720: block 235930089: comm mysqld: 
 unable to read itable block
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1) in 
 ext4_reserve_inode_write:4962: IO failure
 Dec 09 09:27:03 example.server.com iscsiadm[3906]: Logging out of session 
 [sid: 1, target: example.target, portal: 192.168.1.30,3260]
 Dec 09 09:27:03 example.server.com iscsiadm[3906]: Logout of [sid: 1, 
 target: example.target, portal: 192.168.1.30,3260] successful.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped Login and scanning 
 of iSCSI devices.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Open-iSCSI...
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped Open-iSCSI.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped MySQL database.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopping System Time 
 Synchronized.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target System Time 
 Synchronized.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Remote File 
 Systems.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Remote File 
 Systems.
 Dec 09 09:27:03 example.server.com systemd[1]: Unmounting /iscsi-disk...
 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Host and Network 
 Name Lookups.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Host and 
 Network Name Lookups.
 Dec 09 09:27:03 example.server.com kernel: Buffer I/O error on device 
 sdb1, logical block 40960
 Dec 09 09:27:03 example.server.com iscsid[853]: Connection1:0 to [target: 
 example.target, portal: 192.168.1.30,3260] through [iface: default] 
 Dec 09 09:27:03 example.server.com iscsid[853]: iscsid shutting down.
 Dec 09 09:27:03 example.server.com mysqld_safe[1694]: 141209 09:27:03 
 mysqld_safe mysqld from pid file /backup/mysql-bacula/data/mysqld.pid ended
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs warning (device sdb1): 
 ext4_end_bio:287: I/O error writing to inode 58989720 (offset 0 size 4096 
 starting block 40960)
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): 
 ext4_find_entry:1309: inode #58982448: comm mysqld_safe: reading directory 
 lblock 0
 Dec 09 09:27:03 example.server.com kernel: Aborting journal on device 
 sdb1-8.
 Dec 09 09:27:03 example.server.com kernel: Buffer I/O error on device 
 sdb1, logical block 133726208
 Dec 09 09:27:03 example.server.com kernel: lost page write due to I/O 
 error on sdb1
 Dec 09 09:27:03 example.server.com kernel: JBD2: Error -5 detected when 
 updating journal superblock for sdb1-8.
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): 
 ext4_put_super:789: Couldn't clean up the journal
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs (sdb1): Remounting 
 filesystem read-only
 Dec 09 09:27:03 example.server.com systemd[1]: Unmounted /iscsi-disk.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Network is Online.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Network is 
 Online.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Network.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Network.

 Any help would be greatly appreciated.


-- 
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: CentOS7 and systemd ordering when shutting down results in unclean unmount

[The Lee-Man]

It seems clear that the I/O error is because iscsi is stopped before the 
device is unmounted:

On Tuesday, December 9, 2014 7:28:52 AM UTC-8, awidde...@hotmail.com wrote:

 Setup iSCSI on CentOS7. Mounted a iSCSI disk and am running a small MySQL 
 instance on the disk. The iSCSI disk and MySQL instance all come online 
 fine with booting but when shutting down things seem to get very upset and 
 the drive does not get unmounted cleanly.

 Does not look like I'm the only one having the issue. Another report that 
 is very similar was posted here:

 https://www.centos.org/forums/viewtopic.php?f=47t=49337

 This might be a systemd issue but figured I'd post here first to see if 
 anyone else has had this issue and has any suggestions.

 Relevant version info:

 CentOS Linux release 7.0.1406 (Core)
 systemd-208-11.el7_0.4.x86_64
 iscsi-initiator-utils-6.2.0.873-21.el7.x86_64

 Systemd unit file for MySQL server:

 [Unit]
 Description=MySQL Server
 After=nss-lookup.target network.target remote-fs.target time-sync.target
 Wants=nss-lookup.target network.target remote-fs.target time-sync.target

 Logs from journalctl:

 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): 
 __ext4_get_inode_loc:4039: inode #58989720: block 235930089: comm mysqld: 
 unable to read itable block
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1) in 
 ext4_reserve_inode_write:4962: IO failure
 Dec 09 09:27:03 example.server.com iscsiadm[3906]: Logging out of session 
 [sid: 1, target: example.target, portal: 192.168.1.30,3260]
 Dec 09 09:27:03 example.server.com iscsiadm[3906]: Logout of [sid: 1, 
 target: example.target, portal: 192.168.1.30,3260] successful.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped Login and scanning 
 of iSCSI devices.


This looks like a race condition between the SQL shutdown and stopping the 
iscsi.service iSCSI login service.
 

 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Open-iSCSI...
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped Open-iSCSI.


There should be no more iSCSI from here on, right? But it turns out that 
stopping the iscsid service doesn't actually wait for the service to stop 
before it continues on to the next systemd task. (See below)
 

 Dec 09 09:27:03 example.server.com systemd[1]: Stopped MySQL database.


But isn't your MySQL database using an iSCSI target?
 

 Dec 09 09:27:03 example.server.com systemd[1]: Stopping System Time 
 Synchronized.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target System Time 
 Synchronized.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Remote File 
 Systems.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Remote File 
 Systems.
 Dec 09 09:27:03 example.server.com systemd[1]: Unmounting /iscsi-disk...


And now systemd tried to unmount the iscsi-backed device, but iscsid is 
already trying to stop. That's not going to work.
 

 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Host and Network 
 Name Lookups.
 Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Host and 
 Network Name Lookups.
 Dec 09 09:27:03 example.server.com kernel: Buffer I/O error on device 
 sdb1, logical block 40960


And, sure enough, I/O to/from the iSCSI device is failing.
 

 Dec 09 09:27:03 example.server.com iscsid[853]: Connection1:0 to [target: 
 example.target, portal: 192.168.1.30,3260] through [iface: default] 
 Dec 09 09:27:03 example.server.com iscsid[853]: iscsid shutting down.


And iscsid finally finishes. It actually took less than a second ...
 

 Dec 09 09:27:03 example.server.com mysqld_safe[1694]: 141209 09:27:03 
 mysqld_safe mysqld from pid file /backup/mysql-bacula/data/mysqld.pid ended
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs warning (device sdb1): 
 ext4_end_bio:287: I/O error writing to inode 58989720 (offset 0 size 4096 
 starting block 40960)
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): 
 ext4_find_entry:1309: inode #58982448: comm mysqld_safe: reading directory 
 lblock 0
 Dec 09 09:27:03 example.server.com kernel: Aborting journal on device 
 sdb1-8.
 Dec 09 09:27:03 example.server.com kernel: Buffer I/O error on device 
 sdb1, logical block 133726208
 Dec 09 09:27:03 example.server.com kernel: lost page write due to I/O 
 error on sdb1
 Dec 09 09:27:03 example.server.com kernel: JBD2: Error -5 detected when 
 updating journal superblock for sdb1-8.
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): 
 ext4_put_super:789: Couldn't clean up the journal
 Dec 09 09:27:03 example.server.com kernel: EXT4-fs (sdb1): Remounting 
 filesystem read-only
 Dec 09 09:27:03 example.server.com systemd[1]: Unmounted /iscsi-disk.


This is all the filesystem trying and retrying to finish it's I/O before it 
gives up and lets you unmount the now-unreachable device.
 

 Dec 09 09:27:03 example.server.com systemd[1]: Stopping Network is Online.
 Dec 09 09:27:03 example.server.com 

Re: CentOS7 and systemd ordering when shutting down results in unclean unmount

[The Lee-Man]

Okay, I'm no systemd expert, though I play one at work. :)

You might try adding this to your mysql unit file:

 [Unit]
 Description=MySQL Server
-After=nss-lookup.target network.target remote-fs.target time-sync.target
-Wants=nss-lookup.target network.target remote-fs.target time-sync.target
+After=nss-lookup.target network.target remote-fs.target time-sync.target 
iscsi-disk.mount
+Wants=nss-lookup.target network.target remote-fs.target time-sync.target 
iscsi-disk.mount

And, of course, run systemctl daemon-reload after the change.

This is probably an issue for the mysql package maintainers, but this might 
get you working.

On Tuesday, December 9, 2014 10:29:09 AM UTC-8, awidde...@hotmail.com wrote:

 I have tried this same process without any services running on the iSCSI 
 drive and it seems to unmount without issue. Probably because nothing is 
 trying to write to it so no I/O issues would arise. 

 I agree with your log analysis that it doesn't seem like the order 
 requested by the iscsi, iscsid, MySQL and iscsi-disk.mount files is being 
 enforced or things are not stopping when they say they are. The ordering 
 requested in those unit files seems sane to me though.

 The order should be as follows:

 Stop MySQL
 Unmount remote-fs (/iscsi-disk)
 Stop iscsi (logout of targets)
 Stop iscsid

 Again, I'm not sure why it seems like iscsi, iscsid services are stopping 
 before MySQL is stopped or more importantly, before /iscsi-disk is 
 unmounted.

 I find debugging systemd and ordering particularly difficult because it 
 starts/stops multiple things at once so when looking at the log files I'm 
 not sure if the order in which things are logged is the order in which 
 things actually happened.


-- 
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.

Problem setting host net params via iscsiuio on first try: bad error message

[The Lee-Man]

Hi Mike:

I have started working more with iscsiuio.

I have discovered what I consider a bug in an error message printed during 
normal operation of iscsiadm that makes it seem like something bad happened.

As you know, when performing discovery via the bnx2i transport and the 
iscsiuio daemon, the iscsiadm command tries to set up host parameters when 
a target is discovered. The iscsiadm command does this by sending a message 
to the iscsiuio daemon, who actually does the work in this case and then 
normally returns that information.

But it looks like the design of iscsiuio is that it does not even try to 
set up the NIC it is using very first time its called. Instead, it 
initializes the NIC only when the first attempt to use it is received, 
while it returns EAGAIN to the caller. The protocol evidently is that the 
caller knows to retry. In this case, the iscsiadm code retries several 
times no matter what error is returned. In fact, the iscsiadm code being 
used translates all errors received from this attempt to talk to iscsiuio 
into an INTERNAL_ERROR, and the communication is retried anyway.

This translation is the only problem, IMHO, and resulted in these messages 
from iscsiadm, which are misleading (and poorly formatted):

 iscsiadm: Could not set host net params (err 29)

 iscsiadm: Connection to discovery portal 10.125.128.120 failed: internal 
error
 ...

which becomes, with my patches:

 iscsiadm: Could not set host net params (err 29)
 iscsiadm: Connection to discovery portal 192.168.30.1 failed: operation 
failed but retry may succeed
 ...

The fix is simple: in the case where iscsiuio returns EAGAIN, let it 
through. (And fix the error message printing so we don't core dump, of 
course.)

I thought about a more aggressive fix, i.e. letting all return values from 
the communications attempt through, but I worried about fixing something 
that is not really broken and perhaps breaking something else. So, in the 
spirit of fixing just what is broken, I submit two patches:

0001-Supply-strings-for-newly-added-error-numbers.patch: This patch is 
needed by the second patch, though it stands alone. This patch fixes the 
problem that a couple of new error codes have been added to the open-iscsi 
package but the array of error strings used to convert those errors into 
printed messages has not kept pace. So two missing error messages are added.

0002-Allow-setting-host-params-to-return-EAGAIN-errors.patch - This is the 
simple patch that allows EAGAIN errors through when trying to talk to 
iscsiuio. If you want the more aggressive version please let me know.

-- 
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.
From 639308da324773203fc6ae019fd820de9765ac1f Mon Sep 17 00:00:00 2001
From: Lee Duncan ldun...@suse.com
Date: Wed, 10 Dec 2014 15:57:31 -0800
Subject: [PATCH] Supply strings for newly-added error numbers

A couple of new errors have been added to the
iscsi_err enum list, but iscsi_err_msgs[] was
not updated to match, so this adds messages for
the two newly-added errors to the list.

Signed-off-by: Lee Duncan ldun...@suse.com
---
 usr/iscsi_err.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/usr/iscsi_err.c b/usr/iscsi_err.c
index 4fe1c53adce0..1973e6fcd6a1 100644
--- a/usr/iscsi_err.c
+++ b/usr/iscsi_err.c
@@ -51,6 +51,8 @@ static char *iscsi_err_msgs[] = {
 	/* 26 */ iSNS registration failed,
 	/* 27 */ operation not supported,
 	/* 28 */ device or resource in use,
+	/* 29 */ operation failed but retry may succeed,
+	/* 30 */ unknown discovery type,
 };
 
 char *iscsi_err_to_str(int err)
-- 
2.1.2

From fc0e7b10b0ecaebbda85e48a9b188485c2b0ddaf Mon Sep 17 00:00:00 2001
From: Lee Duncan ldun...@suse.com
Date: Thu, 11 Dec 2014 11:17:25 -0800
Subject: [PATCH] Allow setting host params to return EAGAIN errors.

When iscsiadm is talking to iscsiuio, the first
attempt to set host params always fails with
EAGAIN and succeeds on the next try. The error
message was of:

 iscsiadm: Could not set host net params (err 29)

 iscsiadm: Connection to discovery portal 10.125.128.120 failed: internal error

becomes:

 iscsiadm: Could not set host net params (err 29)
 iscsiadm: Connection to discovery portal 192.168.30.1 failed: operataion failed but retry may succeed

Note that in both cases the target is discovered
correctly on the second try.

Signed-off-by: Lee Duncan ldun...@suse.com
---
 usr/discovery.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/usr/discovery.c b/usr/discovery.c
index 635ec8d9403d..565a919ba7e3 100644
--- a/usr/discovery.c
+++ b/usr/discovery.c
@@ -1109,9 +1109,10 @@ static int 

Re: Problem setting host net params via iscsiuio on first try: bad error message

[The Lee-Man]

On Friday, December 12, 2014 12:26:00 PM UTC-8, Mike Christie wrote:

 On 12/12/2014 12:30 PM, Mike Christie wrote: 
  On 12/11/2014 01:53 PM, The Lee-Man wrote: 
  Hi Mike: 
  
  I have started working more with iscsiuio. 
  
  I have discovered what I consider a bug in an error message printed 
  during normal operation of iscsiadm that makes it seem like something 
  bad happened. 
  
  As you know, when performing discovery via the bnx2i transport and the 
  iscsiuio daemon, the iscsiadm command tries to set up host parameters 
  when a target is discovered. The iscsiadm command does this by sending 
 a 
  message to the iscsiuio daemon, who actually does the work in this case 
  and then normally returns that information. 
  
  But it looks like the design of iscsiuio is that it does not even try 
 to 
  set up the NIC it is using very first time its called. Instead, it 
  initializes the NIC only when the first attempt to use it is received, 
  while it returns EAGAIN to the caller. The protocol evidently is that 
  the caller knows to retry. In this case, the iscsiadm code retries 
  several times no matter what error is returned. In fact, the iscsiadm 
  code being used translates all errors received from this attempt to 
 talk 
  to iscsiuio into an INTERNAL_ERROR, and the communication is retried 
  anyway. 
  
  This translation is the only problem, IMHO, and resulted in these 
  messages from iscsiadm, which are misleading (and poorly formatted): 
  
   iscsiadm: Could not set host net params (err 29) 
  
   iscsiadm: Connection to discovery portal 10.125.128.120 failed: 
  internal error 
   ... 
  
  which becomes, with my patches: 
  
   iscsiadm: Could not set host net params (err 29) 
   iscsiadm: Connection to discovery portal 192.168.30.1 failed: 
 operation 
  failed but retry may succeed 
   ... 
  
  The fix is simple: in the case where iscsiuio returns EAGAIN, let it 
  through. (And fix the error message printing so we don't core dump, of 
  course.) 
  
  I thought about a more aggressive fix, i.e. letting all return values 
  from the communications attempt through, but I worried about fixing 
  something that is not really broken and perhaps breaking something 
 else. 
  So, in the spirit of fixing just what is broken, I submit two patches: 
  
  That is not how we do it. Just like in that other thread about the sysfs 
  scanning. We want to fix the root cause and also any issues that result 
  from it. 
  
  Please just fix this properly. It is really silly that the user would 
  have to run this command twice to actually do discovery. 

 Hi Lee, 

 I want to apologize for being a jerk above. The email is unprofessional. 
 I value your submissions and help on this project. I have no excuse, and 
 request that you please continue to help out and be part of this project 

 Mike 


Mike: I apologize for taking it personally. No harm no foul. 

-- 
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: Linux kernel development reports for the 3.17 release

[The Lee-Man]

If corporations can be people I guess google groups can too!

On Monday, December 15, 2014 2:30:54 PM UTC-8, Greg KH wrote:

 Hi, 

 I'm trying to keep track of the different companies that people are 
 working for, or if people are just doing this as a hobby, or being paid 
 as a consultant for future articles on lwn.net about who is doing the 
 work on the Linux kernel. 

 Jonathan Corbet has also been writing articles at lwn.net about this 
 topic, and we share the same set of scripts, as well as we write a 
 yearly article for the Linux Foundation about Linux kernel 
 contributions.  An example of this can be found at: 
 http://www.linuxfoundation.org/publications/whowriteslinux.pdf 

 Your email address shows up in the changelog for the 3.16 kernel 
 release as a contributor, but I can't seem to place it with a company. 
 If you don't mind, could you let me know what company you work for?  Or 
 if no company, do you want to be classified in any of these other 
 categories instead: 
 - Amateur/Hobbyist/Unaffiliated/None 
   - this category is for people who are doing kernel work, but 
 not getting paid by any corporation to do it. 
 - Consultant 
   - this category is for people who are consultants working on 
 the kernel and getting paid by other companies (not your 
 own) to do the work 
 - Academia 
   - this category is for people working for Universities and 
 doing kernel work as part of their research or other 
 responsibilities related to school work. 
 - Unknown 
   - this category is for people who want to remain in the 
 unknown category. 

 If you want, this mapping will be kept private and only myself and Jon 
 Corbet (of lwn.net) will have access to it. 

 The scripts involved in this can be found at: 
 https://github.com/gregkh/kernel-history 
 if you are curious. 

 If you have any questions about this, please let me know. 

 If you never want me to bother you with this again, just let me know and 
 I will be glad to take you off of my list. 

 Thank you for your time, 

 greg k-h 


-- 
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: iscsid stop using system not working correctly

[The Lee-Man]

Thanks, Chris, for tracking down the systemd problem and reporting it.

-- 
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.

iscsid stop using system not working correctly

[The Lee-Man]

Hi Mike:

Just a heads up that stopping the open-iscsi iscsid daemon using systemd 
doesn't seem to be working correctly, at least not on SUSE SLE 12.

When I have one or more sessions present, and their startup value is set to 
manual, when I try to stop the iscsid service, I get:

# systemctl stop iscsid.service
Job for iscsid.service canceled.

And a ps shows that iscsid is still running, but under a new process id. 
And, at times, I see that iscsiadm -k 0 2 is hung.

Note that my systemd iscsid.service unit file looks like:

[Unit]
Description=Open-iSCSI
Documentation=man:iscsid(8) man:iscsiuio(8) man:iscsiadm(8)
DefaultDependencies=no
After=network.target iscsiuio.service
Before=remote-fs-pre.target

[Service]
Type=simple
ExecStart=/sbin/iscsid -f
ExecStop=/sbin/iscsiadm -k 0 2

[Install]
WantedBy=multi-user.target
Also=iscsid.socket

While trying to track down this problem, I found a couple of issues:

1. I don't know what the 2 is on the iscsiadm -k 0 2 is for. I see that 
command in systemd unit file in your master branch, and I see that other 
distributions use that, but the 2 seems to be ignored.

2. It looks like the iscsiadm -k 0 is stopping the iscsi daemon, but that 
systemd is restarting it! I'm guessing this because (a) I get the 
cancelled message, and (b) iscsid is still running, but as a new process, 
i.e. it's been restarted.

I thought perhaps the problem was related to running iscsid as a simple 
service, in the foreground, but changing Type to forking and removing the 
-f from the iscsid command line did not change anything.

Then I simply commented out the ExecStop line, and iscsid now shutdowns 
correctly. This, I believe, is because systemd is shutting it down by 
sending first SIGHUP then SIGKILL, as per man systemd.kill.

Before I comment out the ExecStop= for all SLE 12 users, I wondered if 
you've heard of any problems along these lines.

-- 
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: iscsid stop using system not working correctly

[The Lee-Man]

On Friday, January 30, 2015 at 2:09:54 PM UTC-8, The Lee-Man wrote:

 Hi Mike:

 Just a heads up that stopping the open-iscsi iscsid daemon using systemd 
 doesn't seem to be working correctly, at least not on SUSE SLE 12.

 When I have one or more sessions present, and their startup value is set 
 to manual, when I try to stop the iscsid service, I get:

 # systemctl stop iscsid.service
 Job for iscsid.service canceled.

 And a ps shows that iscsid is still running, but under a new process id. 
 And, at times, I see that iscsiadm -k 0 2 is hung.

 Note that my systemd iscsid.service unit file looks like:

 [Unit]
 Description=Open-iSCSI
 Documentation=man:iscsid(8) man:iscsiuio(8) man:iscsiadm(8)
 DefaultDependencies=no
 After=network.target iscsiuio.service
 Before=remote-fs-pre.target

 [Service]
 Type=simple
 ExecStart=/sbin/iscsid -f
 ExecStop=/sbin/iscsiadm -k 0 2

 [Install]
 WantedBy=multi-user.target
 Also=iscsid.socket

 While trying to track down this problem, I found a couple of issues:

 1. I don't know what the 2 is on the iscsiadm -k 0 2 is for. I see 
 that command in systemd unit file in your master branch, and I see that 
 other distributions use that, but the 2 seems to be ignored.

 2. It looks like the iscsiadm -k 0 is stopping the iscsi daemon, but 
 that systemd is restarting it! I'm guessing this because (a) I get the 
 cancelled message, and (b) iscsid is still running, but as a new process, 
 i.e. it's been restarted.

 I thought perhaps the problem was related to running iscsid as a simple 
 service, in the foreground, but changing Type to forking and removing the 
 -f from the iscsid command line did not change anything.

 Then I simply commented out the ExecStop line, and iscsid now shutdowns 
 correctly. This, I believe, is because systemd is shutting it down by 
 sending first SIGHUP then SIGKILL, as per man systemd.kill.

 Before I comment out the ExecStop= for all SLE 12 users, I wondered if 
 you've heard of any problems along these lines.


I believe I found out more about the problem. It is because the iscsid 
service is socket-activated. There is an iscsid.socket service file, and 
that is used to wake up and start iscsid if iscsiadm tries to talk to 
iscsid and iscsid is not running.

I believe that what is happening is that:
1. iscsiadm tells iscsid to stop using a socket that systemd is monitoring
2. iscsid gets the message, cleans up, closes the socket, and exits
3. systemd restarts the service because the socket communication failed
4. systemd returns failure on the message (the ...cancelled message) and 
restarts the iscsid service that just stopped

I looked for some systemd.socket(5) variable that would control this, but I 
see none.

I think the fundamental problem is that I am trying to stop a service via 
the socket that
was used to socket-activate the process. Kind of like trying to put away a 
ladder I am standing on. :)

-- 
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: Problem setting host net params via iscsiuio on first try: bad error message

[The Lee-Man]

Hi Mike:

I verified this patch works. Feel free to add a Tested-by:.

By works, I mean that it eliminated the retry that I was seeing when
connecting the first time to the iscsiuio daemon.

On Tuesday, March 10, 2015 at 8:00:54 AM UTC-7, Mike Christie wrote:

 On 03/09/2015 08:54 PM, Lee Duncan wrote: 
  Hi Mike: 
  
  I am *finally* getting to this bug, previously buried under a mountain 
 of more pressing matters. 
  
  On Jan 12, 2015, at 12:50 PM, Mike Christie mich...@cs.wisc.edu 
 javascript: wrote: 
  
  Thanks. I merged and pushed these patches. 
  
  When you get some time, reply to that mail I sent offlist about how 
 long 
  it is taking for the set host net params to succeed, so I can fix my 
  login/init patch as needed. 
  
  I have looked at this problem again, and I will reply in a new email 
 tomorrow. Fair warning. :) 

 :) 

 Hey, 

 Attached is the patch that was modifying iscsid's code path which from 
 what I understand handled the same problem you were handling in the 
 iscsiadm's discovery code path. 

 The patch is removing the iscsiuio specific calls in iscsid and using 
 the generic initial login/connect retry code. It is currently retrying 
 for up to login_timeout seconds instead of the hard coded 5 seconds. 


-- 
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: Problem setting host net params via iscsiuio on first try: bad error message

[The Lee-Man]

Oops. I almost forgot. The patch did not apply cleanly because of a recent
update you did. Please make sure I modified it correctly (attached).


On Monday, March 16, 2015 at 11:56:48 AM UTC-7, The Lee-Man wrote:
Hi Mike:

I verified this patch works. Feel free to add a Tested-by:.

By works, I mean that it eliminated the retry that I was seeing when
connecting the first time to the iscsiuio daemon.

On Tuesday, March 10, 2015 at 8:00:54 AM UTC-7, Mike Christie wrote:
On 03/09/2015 08:54 PM, Lee Duncan wrote: 
 Hi Mike: 
 
 I am *finally* getting to this bug, previously buried under a mountain of 
more pressing matters. 
 
 On Jan 12, 2015, at 12:50 PM, Mike Christie mich...@cs.wisc.edu wrote: 
 
 Thanks. I merged and pushed these patches. 
 
 When you get some time, reply to that mail I sent offlist about how long 
 it is taking for the set host net params to succeed, so I can fix my 
 login/init patch as needed. 
 
 I have looked at this problem again, and I will reply in a new email 
tomorrow. Fair warning. :) 

:) 

Hey, 

Attached is the patch that was modifying iscsid's code path which from 
what I understand handled the same problem you were handling in the 
iscsiadm's discovery code path. 

The patch is removing the iscsiuio specific calls in iscsid and using 
the generic initial login/connect retry code. It is currently retrying 
for up to login_timeout seconds instead of the hard coded 5 seconds. 

-- 
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.
From 31c26a00bbfa6cff83040eb3780a7e1753409aaa Mon Sep 17 00:00:00 2001
From: Mike Christie micha...@cs.wisc.edu
Date: Mon, 16 Mar 2015 11:52:50 -0700
Subject: [PATCH] iscsid: make sure actor is delayed before rescheduling

iscsi_conn_connect() be called from a login_timer that is not deleted.
This causes it to be scheduled multiple times. This patch adds a new
function actor_timer_mod to handle both deletion and rescheduling.

This patch also then removed the uio poll code which was using the
login_timer to schedule itself. This uio retry, is now just done in
the generic initial login retry.
---
 usr/actor.c|   8 
 usr/actor.h|   3 +-
 usr/initiator.c| 120 +
 usr/initiator.h|   1 -
 usr/initiator_common.c |   8 ++--
 5 files changed, 25 insertions(+), 115 deletions(-)

diff --git a/usr/actor.c b/usr/actor.c
index 67ae0e036ce4..017d013fb596 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -195,6 +195,14 @@ actor_timer(actor_t *thread, uint32_t timeout_secs, void (*callback)(void *),
 	actor_schedule_private(thread, timeout_secs, 0);
 }
 
+void
+actor_timer_mod(actor_t *thread, uint32_t new_timeout_secs, void *data)
+{
+	actor_delete(thread);
+	thread-data = data;
+	actor_schedule_private(thread, new_timeout_secs, 0);
+}
+
 /*
  * Execute all items that have expired.
  *
diff --git a/usr/actor.h b/usr/actor.h
index 7283dcebfe1e..f572f2e32af3 100644
--- a/usr/actor.h
+++ b/usr/actor.h
@@ -43,7 +43,8 @@ extern void actor_schedule_head(actor_t *thread);
 extern void actor_schedule(actor_t *thread);
 extern void actor_timer(actor_t *thread, uint32_t delay_secs,
 			void (*callback)(void *), void *data);
-extern int actor_timer_mod(actor_t *thread, uint32_t new_delay_secs, void *data);
+extern void actor_timer_mod(actor_t *thread, uint32_t new_delay_secs,
+			void *data);
 extern void actor_poll(void);
 
 #endif /* ACTOR_H */
diff --git a/usr/initiator.c b/usr/initiator.c
index b25ded81c9d7..542ce0d3179f 100644
--- a/usr/initiator.c
+++ b/usr/initiator.c
@@ -263,6 +263,7 @@ __session_conn_create(iscsi_session_t *session, int cid)
 
 	conn-state = ISCSI_CONN_STATE_FREE;
 	conn-session = session;
+	actor_init(conn-login_timer, iscsi_login_timedout, NULL);
 	/*
 	 * TODO: we must export the socket_fd/transport_eph from sysfs
 	 * so if iscsid is resyncing up we can pick that up and cleanup up
@@ -529,9 +530,7 @@ queue_delayed_reopen(queue_task_t *qtask, int delay)
  	 * iscsi_login_eh can handle the login resched as
  	 * if it were login time out
  	 */
-	actor_delete(conn-login_timer);
-	actor_timer(conn-login_timer, delay,
-		iscsi_login_timedout, qtask);
+	actor_timer_mod(conn-login_timer, delay, qtask);
 }
 
 static int iscsi_conn_connect(struct iscsi_conn *conn, queue_task_t *qtask)
@@ -566,53 +565,10 @@ static int iscsi_conn_connect(struct iscsi_conn *conn, queue_task_t *qtask)
 	iscsi_sched_ev_context(ev_context, conn, 0, EV_CONN_POLL);
 	log_debug(3, Setting login timer %p timeout %d, conn-login_timer,
 		  conn-login_timeout);
-	actor_timer(conn-login_timer, conn-login_timeout

Re: 8 patches for review

[The Lee-Man]

On Monday, June 29, 2015 at 1:38:04 PM UTC-7, Christian Iversen wrote:

 Hello Open-iSCSI 

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


Please join the list if you are going to submit patches. 


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

 Here's a description: 


I am looking at your patches (I'm sure Mike will, as well), but my first 
response is that your descriptions (and hence the names of your patches) 
are not very descriptive.

For example, for your patch 8, remove dead code is too generic. How about 
iscsiuio: remove unused ipv6 header. 


 -- 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. 


Not really. 






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


Yes, should be run-tested as well if you are going to submit this many 
changes, IMHO.

Also, I'd suggest grouping similar changes together. Why create a patch for 
each variable removed? If you are cleaning up unused variables, I would 
group those patches as one. But that might just be me. :) And the two 
memset() fixes should be one patch.

Lastly, you cannot patch open-isns in open-iscsi any longer. You need to 
submit those changes to https://github.com/gonzoleeman/open-isns


 -- 
 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+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

[The Lee-Man]

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.

Re: [PATCH] open-isns: Allow setting server name for isnsadm.

[The Lee-Man]

Note: I fixed this in open-isns in github already, but I thought you might 
want to fix
it here in the meantime. It's up to you.

On Friday, August 21, 2015 at 6:01:34 PM UTC-7, The Lee-Man wrote:

 The switch statement was falling through after 
 the server name was set, into the version code. So 
 setting the server name just printed the version and 
 exited. Added a break statement. 
 --- 
  utils/open-isns/isnsadm.c | 1 + 
  1 file changed, 1 insertion(+) 

 diff --git a/utils/open-isns/isnsadm.c b/utils/open-isns/isnsadm.c 
 index c170595372da..5b14f82b8ce9 100644 
 --- a/utils/open-isns/isnsadm.c 
 +++ b/utils/open-isns/isnsadm.c 
 @@ -141,6 +141,7 @@ main(int argc, char **argv) 
   
  case 's': 
  opt_servername = optarg; 
 +break; 
   
  case 'V': 
  printf(Open-iSNS version %s\n 
 -- 
 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+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: [PATCH] Discovery daemon via non-tcp transport needs 'ipc' set

[The Lee-Man]

Roi: Could you supply your changes?

On Monday, August 10, 2015 at 11:14:48 PM UTC-7, Roi Dayan wrote:

 I also played with discoveryd. found an issue when you have many portals. 
 can be reproduced with iscsiadm.

 The netlink response from the kernel is using multicast. So when we have 
 more than 1 portal there is an issue that multiple forks of the discoveryd 
 handle the same response.
 I noticed that when configured multiple portals and noticed we tried to 
 handle session id 1 more than once and started to get errors about it. 
 seems like iscsid is not handling the error very well and becomes 
 unresponsive and need to kill the process.

 I then used a named mutex in discoveryd to protect the calls 
 to __do_st_disc_and_login() and waited for the connections to complete in 
 update_sessions().
 This way I had 1 discoveryd fork working at a time. This solved the issue 
 with discoveryd only

 You can reproduce the issue with creating multiple discoveryd portals or 
 with iscsiadm if you run it in the background and discovery multiple 
 portals.
 I used this to reproduce the issue with iscsiadm:


 portals=11.212.164.1:3261 11.212.164.1:3262 11.212.164.1:3263 
 11.212.164.1:3264
 for p in $portals; do
 iscsiadm -m discovery -t st -I iser -p $p -l 
 done








 On Mon, Aug 10, 2015 at 10:57 PM, The Lee-Man leeman...@gmail.com 
 javascript: wrote:

 On Tuesday, August 4, 2015 at 8:36:14 AM UTC-7, Mike Christie wrote:

 On 08/04/2015 10:33 AM, Mike Christie wrote: 
  On 08/04/2015 09:45 AM, Roi Dayan wrote: 
  
  
  On Friday, July 24, 2015 at 3:38:00 AM UTC+3, The Lee-Man wrote: 
  
  On Wednesday, July 22, 2015 at 1:43:59 PM UTC-7, Mike Christie 
 wrote: 
  
  On 07/22/2015 10:24 AM, The Lee-Man wrote: 
   On Tuesday, July 21, 2015 at 9:29:19 PM UTC-7, Mike 
 Christie 
  wrote: 
   
   On 07/21/2015 05:47 PM, leeman...@gmail.com 
 javascript: 
  wrote: 
From: Lee Duncan ldu...@suse.com javascript: 

This patch allows iser transport to be used for the 
  discovery 
daemon. Otherwise, iscsid core dumps when attempting 
 this. 
--- 
 usr/discoveryd.c | 5 - 
 1 file changed, 5 deletions(-) 

diff --git a/usr/discoveryd.c b/usr/discoveryd.c 
index 1e149771a50b..2d3ccbcd722f 100644 
--- a/usr/discoveryd.c 
+++ b/usr/discoveryd.c 
@@ -1034,11 +1034,6 @@ static void 
  __do_st_disc_and_login(struct 
   discovery_rec *drec) 
 drec-u.sendtargets.reopen_max = 0; 
  
 iface_link_ifaces(setup_ifaces); 
-/* 
- * disc code assumes this is not set and 
 wants 
  to use 
- * the userspace IO code. 
- */ 
-ipc = NULL; 
  
 rc = 
  idbm_bind_ifaces_to_nodes(discovery_sendtargets, drec, 

  setup_ifaces, 
  rec_list); 

   
   Do you need this patch for offload support too, and 
 does 
  it work ok now 
   too, or was that already working? 
   
   
   That was already working. With this patch, offload via 
 IB/iSER 
  seems 
   to be working for us. 
   
  
  For offload, like bnx2i, was it doing discovery through the 
 offload 
  engine or in software for you? I thought it would crash in 
  iscsi_create_leading_conn when it references the ipc pointer 
 here: 
  
  conn-socket_fd = ipc-ctldev_open(); 
  
  for bnx2i. 
  
  Your patch is correct. I am just trying to figure out why I 
  wrote that 
  disc code assumes comment above. It seems like my comment 
 in 
  the code 
  is very very wrong, because if CAP_TEXT_NEGO, like with 
  bnx2i/cxgb/be2iscsi and in newer kernels where we now set 
 that 
  bit iser, 
  then we want a valid ipc pointer. 
  
  
  I have never tried running the discovery daemon with bnx2i. 
 Regular 
  discovery 
  through bnx2i works fine without this patch. 
  
  So I set it up just now and confirmed: using the discovery daemon 
  for bnx2i 
  also gets a core dump without this patch. And regular discovery 
 is 
  verified 
  as working with or without this patch using bnx2i. 
  
  
  
  Hi, 
  
  any update about this patch ? 
  
  
  Needs more testing and review of the offload code it also enables. I 
 am 
  trying to get to it. 
  

 If offload discoveryd support has gone through a distro QA cycle, let me 
 know. It would be helpful. 


 I did some

Re: [PATCH V2] discoveryd: Lock between forks

[The Lee-Man]

Just an update for the list:

I have replied privately to Roi that I have some issue with this patch, but 
a bigger issue with fixing the discoveryd problem this way, i.e. 
single-threading it.

If I can get a copy of the finer-grained locking code from him I will test 
it out. He says that it has some 2nd-layer issues.

On Sunday, August 23, 2015 at 6:33:02 AM UTC-7, Roi Dayan wrote:

 Since iscsi responses from the kernel are multicast we might get into 
 a situation where multiple discoveryd handle the same response. 
 With this commit we use a shared mutex to lock between the discoveryd 
 forks 
 so each fork will handle its intended portal. 
 So we wait for login and stale logouts to finish between releasing the 
 mutex. 

 Signed-off-by: Roi Dayan ro...@mellanox.com javascript: 
 --- 


 Hi, 

 The issue was discovered after working with discoveryd and offload driver 
 which needed the following patch that was already submitted to the mailing 
 list: 

 [PATCH] Discovery daemon via non-tcp transport needs 'ipc' set 

 Thanks, 
 Roi 


 V2: 
 didn't actually need iscsi_login_portal_wait 


  usr/Makefile |  2 +- 
  usr/discoveryd.c | 57 
 ++-- 
  2 files changed, 56 insertions(+), 3 deletions(-) 

 diff --git a/usr/Makefile b/usr/Makefile 
 index e23fee1..dca7b6e 100644 
 --- a/usr/Makefile 
 +++ b/usr/Makefile 
 @@ -55,7 +55,7 @@ all: $(PROGRAMS) 
   
  iscsid: $(ISCSI_LIB_SRCS) $(INITIATOR_SRCS) $(DISCOVERY_SRCS) \ 
  iscsid.o session_mgmt.o discoveryd.o 
 -$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@  -L../utils/open-isns -lisns 
 -lrt -lmount 
 +$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@  -L../utils/open-isns -lisns 
 -lrt -lmount -pthread 
   
  iscsiadm: $(ISCSI_LIB_SRCS) $(DISCOVERY_SRCS) iscsiadm.o session_mgmt.o 
  $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ -L../utils/open-isns -lisns 
 diff --git a/usr/discoveryd.c b/usr/discoveryd.c 
 index 2d3ccbc..6943662 100644 
 --- a/usr/discoveryd.c 
 +++ b/usr/discoveryd.c 
 @@ -27,6 +27,10 @@ 
  #include time.h 
  #include sys/types.h 
  #include sys/wait.h 
 +#include sys/mman.h 
 +#include sys/stat.h 
 +#include pthread.h 
 +#include fcntl.h 
   
  #include discovery.h 
  #include idbm.h 
 @@ -47,6 +51,9 @@ 
  #include iscsi_err.h 
   
  #define DISC_DEF_POLL_INVL30 
 +#define MUTEX /lock 
 + 
 +pthread_mutex_t *mutex = NULL; 
   
  static LIST_HEAD(iscsi_targets); 
  static int stop_discoveryd; 
 @@ -62,6 +69,43 @@ static void isns_reg_refresh_by_eid_qry(void *data); 
  typedef void (do_disc_and_login_fn)(const char *def_iname, 
  struct discovery_rec *drec, int 
 poll_inval); 
   
 +static void discoveryd_create_shared_mutex(void) 
 +{ 
 +int mode = S_IRWXU | S_IRWXG; 
 +int des_mutex; 
 +pthread_mutexattr_t attr; 
 + 
 +des_mutex = shm_open(MUTEX, O_CREAT | O_RDWR | O_TRUNC, mode); 
 + 
 +if (des_mutex  0) { 
 +log_error(Error creating mutex); 
 +return; 
 +} 
 + 
 +if (ftruncate(des_mutex, sizeof(pthread_mutex_t)) == -1) { 
 +log_error(Error on truncate); 
 +return; 
 +} 
 + 
 +mutex = (pthread_mutex_t*) mmap(NULL, sizeof(pthread_mutex_t), 
 +PROT_READ | PROT_WRITE, MAP_SHARED, des_mutex, 0); 
 + 
 +if (mutex == MAP_FAILED ) { 
 +log_error(Error on mmap); 
 +return; 
 +} 
 + 
 +pthread_mutexattr_init(attr); 
 +pthread_mutexattr_setpshared(attr, PTHREAD_PROCESS_SHARED); 
 +pthread_mutex_init(mutex, attr); 
 +pthread_mutexattr_destroy(attr); 
 +} 
 + 
 +static void discoveryd_destroy_shared_mutex(void) 
 +{ 
 +pthread_mutex_destroy(mutex); 
 +} 
 + 
  static int logout_session(void *data, struct list_head *list, 
struct session_info *info) 
  { 
 @@ -96,6 +140,7 @@ static void discoveryd_stop(void) 
  } 
   
  done: 
 +discoveryd_destroy_shared_mutex(); 
  exit(0); 
  } 
   
 @@ -174,7 +219,7 @@ static void update_sessions(struct list_head 
 *new_rec_list, 
   
  list_for_each_entry_safe(rec, tmp_rec, new_rec_list, list) { 
  if (!iscsi_check_for_running_session(rec)) 
 -iscsi_login_portal_nowait(rec); 
 +iscsi_login_portal(NULL, NULL, rec); 
   
  if (!idbm_find_rec_in_list(iscsi_targets, rec-name, 
 rec-conn[0].address, 
 @@ -190,7 +235,7 @@ static void update_sessions(struct list_head 
 *new_rec_list, 
  } 
   
  if (!list_empty(stale_rec_list)) { 
 -iscsi_logout_portals(stale_rec_list, nr_found, 0, 
 +iscsi_logout_portals(stale_rec_list, nr_found, 1, 
   logout_session); 
  list_for_each_entry_safe(rec, tmp_rec, 

Re: [PATCH 0/2] Remove local open-isns, using system-installed version

[The Lee-Man]

On Wednesday, July 29, 2015 at 9:07:30 PM UTC-7, Mike Christie wrote:

 On 7/14/15, 4:01 PM, leeman...@gmail.com javascript: wrote: 
  From: Lee Duncanldu...@suse.com javascript: 
  
  This set of patches tells open-iscsi to use the system-resident 
  open-isns files instead of the ones in utils/open-isns. 
  
  This patch*requires*  that you've installed open-isns (from 
  g...@github.com:gonzoleeman/open-isns.git). 
  
  The first patch tells open-iscsi to use the system-resident 
  include files and library from open-isns. The second patch 
  removes the local copy of same. 
  
  Questions: 
  - Should the documentation be updated? I didn't 
 find anything that referenced open-isns 

 Yeah, I can update the README to point to your github tree and wherever 
 you are going to put releases. Let me know the link for the latter. 


I created release tags for 0.93, which is an oldest version I saw created 
by you,
and then I updated the README a bit and updated to version 0.94, creating
another tag.

So you can get either version at:

  https://github.com/gonzoleeman/open-isns/archive/VERSION.tar.gz

where VERSION is 0.93 or 0.94


  - Is it perhaps time to bump the minor version 
 of open-iscsi? It's been a while. 

 Yeah, I am going to make a release soon now. There is just one 
 regression that I wanted to fix. I think commit 
 36a8b41de43749d91dfd52f9c8ad4a454c9a8f15 added a bug that slows down 
 setup of multiple sessions. 

  
  Note: it is my intention to create an open-isns package 
  for SUSE. I assume other platforms will have to do the 
  same before they could incorporate this patch. 


-- 
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: [PATCH] Discovery daemon via non-tcp transport needs 'ipc' set

[The Lee-Man]

On Tuesday, August 4, 2015 at 8:36:14 AM UTC-7, Mike Christie wrote:

 On 08/04/2015 10:33 AM, Mike Christie wrote: 
  On 08/04/2015 09:45 AM, Roi Dayan wrote: 
  
  
  On Friday, July 24, 2015 at 3:38:00 AM UTC+3, The Lee-Man wrote: 
  
  On Wednesday, July 22, 2015 at 1:43:59 PM UTC-7, Mike Christie 
 wrote: 
  
  On 07/22/2015 10:24 AM, The Lee-Man wrote: 
   On Tuesday, July 21, 2015 at 9:29:19 PM UTC-7, Mike Christie 
  wrote: 
   
   On 07/21/2015 05:47 PM, leeman...@gmail.com 
 javascript: 
  wrote: 
From: Lee Duncan ldu...@suse.com javascript: 

This patch allows iser transport to be used for the 
  discovery 
daemon. Otherwise, iscsid core dumps when attempting 
 this. 
--- 
 usr/discoveryd.c | 5 - 
 1 file changed, 5 deletions(-) 

diff --git a/usr/discoveryd.c b/usr/discoveryd.c 
index 1e149771a50b..2d3ccbcd722f 100644 
--- a/usr/discoveryd.c 
+++ b/usr/discoveryd.c 
@@ -1034,11 +1034,6 @@ static void 
  __do_st_disc_and_login(struct 
   discovery_rec *drec) 
 drec-u.sendtargets.reopen_max = 0; 
  
 iface_link_ifaces(setup_ifaces); 
-/* 
- * disc code assumes this is not set and wants 
  to use 
- * the userspace IO code. 
- */ 
-ipc = NULL; 
  
 rc = 
  idbm_bind_ifaces_to_nodes(discovery_sendtargets, drec, 
 setup_ifaces, 
  rec_list); 

   
   Do you need this patch for offload support too, and does 
  it work ok now 
   too, or was that already working? 
   
   
   That was already working. With this patch, offload via 
 IB/iSER 
  seems 
   to be working for us. 
   
  
  For offload, like bnx2i, was it doing discovery through the 
 offload 
  engine or in software for you? I thought it would crash in 
  iscsi_create_leading_conn when it references the ipc pointer 
 here: 
  
  conn-socket_fd = ipc-ctldev_open(); 
  
  for bnx2i. 
  
  Your patch is correct. I am just trying to figure out why I 
  wrote that 
  disc code assumes comment above. It seems like my comment in 
  the code 
  is very very wrong, because if CAP_TEXT_NEGO, like with 
  bnx2i/cxgb/be2iscsi and in newer kernels where we now set that 
  bit iser, 
  then we want a valid ipc pointer. 
  
  
  I have never tried running the discovery daemon with bnx2i. Regular 
  discovery 
  through bnx2i works fine without this patch. 
  
  So I set it up just now and confirmed: using the discovery daemon 
  for bnx2i 
  also gets a core dump without this patch. And regular discovery is 
  verified 
  as working with or without this patch using bnx2i. 
  
  
  
  Hi, 
  
  any update about this patch ? 
  
  
  Needs more testing and review of the offload code it also enables. I am 
  trying to get to it. 
  

 If offload discoveryd support has gone through a distro QA cycle, let me 
 know. It would be helpful. 


I did some more testing today. I created a target with discoveryd enabled.

First, I verified it was working normally by setting startup to automatic, 
logging out of the target, and letting the discovery daemon recreate the 
session for me. All was working normally.

Then I logged out of my session from the command line, and deleted the 
node record.

When the discovery daemon next ran for that target, it re-logged in, though 
it did not create the node entry in the database.

So it looks like it worked correct after a node deletion. 

-- 
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: [PATCH] Discovery daemon via non-tcp transport needs 'ipc' set

[The Lee-Man]

On Tuesday, July 21, 2015 at 9:29:19 PM UTC-7, Mike Christie wrote:

 On 07/21/2015 05:47 PM, leeman...@gmail.com javascript: wrote: 
  From: Lee Duncan ldu...@suse.com javascript: 
  
  This patch allows iser transport to be used for the discovery 
  daemon. Otherwise, iscsid core dumps when attempting this. 
  --- 
   usr/discoveryd.c | 5 - 
   1 file changed, 5 deletions(-) 
  
  diff --git a/usr/discoveryd.c b/usr/discoveryd.c 
  index 1e149771a50b..2d3ccbcd722f 100644 
  --- a/usr/discoveryd.c 
  +++ b/usr/discoveryd.c 
  @@ -1034,11 +1034,6 @@ static void __do_st_disc_and_login(struct 
 discovery_rec *drec) 
   drec-u.sendtargets.reopen_max = 0; 

   iface_link_ifaces(setup_ifaces); 
  -/* 
  - * disc code assumes this is not set and wants to use 
  - * the userspace IO code. 
  - */ 
  -ipc = NULL; 

   rc = idbm_bind_ifaces_to_nodes(discovery_sendtargets, drec, 
   setup_ifaces, rec_list); 
  

 Do you need this patch for offload support too, and does it work ok now 
 too, or was that already working? 


That was already working. With this patch, offload via IB/iSER seems
to be working for us. 

-- 
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: [PATCH] Discovery daemon via non-tcp transport needs 'ipc' set

[The Lee-Man]

On Wednesday, July 22, 2015 at 1:43:59 PM UTC-7, Mike Christie wrote:

 On 07/22/2015 10:24 AM, The Lee-Man wrote: 
  On Tuesday, July 21, 2015 at 9:29:19 PM UTC-7, Mike Christie wrote: 
  
  On 07/21/2015 05:47 PM, leeman...@gmail.com javascript: wrote: 
   From: Lee Duncan ldu...@suse.com javascript: 
   
   This patch allows iser transport to be used for the discovery 
   daemon. Otherwise, iscsid core dumps when attempting this. 
   --- 
usr/discoveryd.c | 5 - 
1 file changed, 5 deletions(-) 
   
   diff --git a/usr/discoveryd.c b/usr/discoveryd.c 
   index 1e149771a50b..2d3ccbcd722f 100644 
   --- a/usr/discoveryd.c 
   +++ b/usr/discoveryd.c 
   @@ -1034,11 +1034,6 @@ static void __do_st_disc_and_login(struct 
  discovery_rec *drec) 
drec-u.sendtargets.reopen_max = 0; 
 
iface_link_ifaces(setup_ifaces); 
   -/* 
   - * disc code assumes this is not set and wants to use 
   - * the userspace IO code. 
   - */ 
   -ipc = NULL; 
 
rc = idbm_bind_ifaces_to_nodes(discovery_sendtargets, 
 drec, 
setup_ifaces, 
 rec_list); 
   
  
  Do you need this patch for offload support too, and does it work ok 
 now 
  too, or was that already working? 
  
  
  That was already working. With this patch, offload via IB/iSER seems 
  to be working for us. 
  

 For offload, like bnx2i, was it doing discovery through the offload 
 engine or in software for you? I thought it would crash in 
 iscsi_create_leading_conn when it references the ipc pointer here: 

 conn-socket_fd = ipc-ctldev_open(); 

 for bnx2i. 

 Your patch is correct. I am just trying to figure out why I wrote that 
 disc code assumes comment above. It seems like my comment in the code 
 is very very wrong, because if CAP_TEXT_NEGO, like with 
 bnx2i/cxgb/be2iscsi and in newer kernels where we now set that bit iser, 
 then we want a valid ipc pointer. 


I have never tried running the discovery daemon with bnx2i. Regular 
discovery
through bnx2i works fine without this patch.

So I set it up just now and confirmed: using the discovery daemon for bnx2i
also gets a core dump without this patch. And regular discovery is verified
as working with or without this patch using bnx2i. 

-- 
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: Antw: [PATCH v2 1/2] iscsid: Changes to support ping through iscsiuio

[The Lee-Man]

On Sunday, July 12, 2015 at 9:35:07 PM UTC-7, Adheer Chandravanshi wrote:



  -Original Message- 
  From: open-...@googlegroups.com javascript: [mailto:
 open-...@googlegroups.com javascript:] 
  On Behalf Of Ulrich Windl 
  Sent: Friday, July 10, 2015 11:32 AM 
  Cc: open-iscsi 
  Subject: Antw: [PATCH v2 1/2] iscsid: Changes to support ping through 
  iscsiuio 
  
   adheer.cha...@qlogic.com javascript: schrieb am 09.07.2015 um 
 13:38 in 
   Nachricht 
  1436441896-7161-2-git-send-email-adheer.chandravan...@qlogic.com 
 javascript:: 
   From: Adheer Chandravanshi adheer.cha...@qlogic.com javascript: 
   
   These changes are done in order to support ping operation for drivers 
   like bnx2i that use iscsiuio. 
   
   Signed-off-by: Adheer Chandravanshi 
  adheer.cha...@qlogic.com javascript: 
   --- 
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? 
  
  

 status is used to get the status of ping from iscsiuio. 
 It will either contain the defined ping status or errno if ping fails due 
 to some other problem. 
 So, strerror() is used only when status holds some errno . 
 And iscsi_ping_stat_strs[status] is used to return corresponding string 
 for ping status code. 


I would suggest adding a comment to that effect, then, since many might 
have the same question.
 

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: [PATCH 0/3] open-isns: prepare for external use by open-iscsi

[The Lee-Man]

If there are no objections I will commit these changes. Then I'll submit a 
set of patches for open-iscsi to use this package instead of it's internal 
copy of it.

Sound good Mike?

On Monday, July 13, 2015 at 2:57:45 PM UTC-7, The Lee-Man wrote:

 From: Lee Duncan ldun...@suse.com 

 This group of patches is for open-isns, and the current procedure for 
 changes to open-isns is to share them on the open-iscsi mailing list. 

 The goal of these patches is to make open-isns a stand-alone package 
 that can be used by other (like open-iscsi). This way clients don't 
 have to have their own (possibly stale) copies of these files. 

 NOTE: there are NO FUNCTIONAL CHANGES here, just: 
 * moving some inclue files locally to include/libisns directory 
 * changing all users of include files to know new location 
 * Adding install_lib and install_hdrs Makefile targets 

 This has been tested with open-iscsn and seems to work. 

 Lee Duncan (3): 
   Move public inlcude files to libisns/*.h 
   Make one more include file public. 
   Add test binaries as 'make clean' targets. 

  Makefile.in  |  27 +- 
  attrs.c  |   6 +- 
  attrs.h  | 262 - 
  authblock.c  |   8 +- 
  bitvector.c  |   4 +- 
  buffer.c |   4 +- 
  buffer.h | 141 - 
  callback.c   |   6 +- 
  client.c |   4 +- 
  config.c |   6 +- 
  db-file.c|   6 +- 
  db-policy.c  |   4 +- 
  db.c |   4 +- 
  db.h |   2 +- 
  dd.c |   8 +- 
  deregister.c |   8 +- 
  domain.c |   4 +- 
  entity.c |   4 +- 
  error.c  |   2 +- 
  esi.c|   8 +- 
  export.c |   8 +- 
  getnext.c|   8 +- 
  include/libisns/attrs.h  | 262 + 
  include/libisns/buffer.h | 141 + 
  include/libisns/isns-proto.h | 259 + 
  include/libisns/isns.h   | 676 
 +++ 
  include/libisns/message.h| 196 + 
  include/libisns/paths.h  |  24 ++ 
  include/libisns/source.h |  32 ++ 
  include/libisns/types.h  |  57  
  include/libisns/util.h   | 288 ++ 
  isns-proto.h | 259 - 
  isns.h   | 676 
 --- 
  isnsadm.c|   8 +- 
  isnsd.c  |   6 +- 
  isnsdd.c |  10 +- 
  local.c  |  12 +- 
  logging.c|   2 +- 
  mdebug.c |   2 +- 
  message.c|   8 +- 
  message.h| 196 - 
  objects.c|   8 +- 
  objects.h|   4 +- 
  parser.c |   2 +- 
  paths.h  |  24 -- 
  pidfile.c|   2 +- 
  pki.c|   4 +- 
  policy.c |   6 +- 
  portal-group.c   |   6 +- 
  query.c  |   8 +- 
  register.c   |   8 +- 
  relation.c   |   4 +- 
  scn.c|   8 +- 
  scope.c  |   8 +- 
  security.c   |   6 +- 
  security.h   |   4 +- 
  server.c |   6 +- 
  simple.c |   8 +- 
  slp.c|   4 +- 
  socket.c |   6 +- 
  socket.h |   6 +- 
  source.h |  32 -- 
  storage-node.c   |   4 +- 
  sysdep-unix.c|   4 +- 
  tags.c   |   6 +- 
  tests/pauw1.c|   8 +- 
  tests/pauw2.c|   8 +- 
  tests/pauw3.c|   8 +- 
  tests/pauw4.c|   8 +- 
  timer.c  |   4 +- 
  types.h  |  57  
  util.c   |   2 +- 
  util.h   | 288 -- 
  vendor.c |   6 +- 
  vendor.h |   2 +- 
  75 files changed, 2121 insertions(+), 2096 deletions(-) 
  delete mode 100644 attrs.h 
  delete mode 100644 buffer.h 
  create mode 100644 include/libisns/attrs.h 
  create mode 100644 include/libisns/buffer.h 
  create mode 100644 include/libisns/isns-proto.h 
  create mode 100644 include/libisns/isns.h 
  create mode 100644 include/libisns/message.h 
  create mode 100644 include/libisns/paths.h 
  create mode 100644 include/libisns/source.h 
  create mode 100644 include/libisns/types.h 
  create mode 100644 include/libisns/util.h 
  delete mode 100644 isns-proto.h 
  delete mode 100644 isns.h 
  delete mode

Updated open-isns to 0.95

[The Lee-Man]

Hello all:

I've added a couple of bug fixes to open-isns, and updated the version to 
0.95.

Here's a summary of the changes:

3af749e0c8e1 Bump version to 0.95
6d794c22c867 isnsd exit(0) when terminated with SIGTERM
d1495f23cca5 Be more robust when dealing with the database
2f2aa4ef102f Remove isnsd debugging output
7b4fd0cb8384 Ensure we can reliably get our local IP address.
7754e18e22a9 Allow setting server name for isnsadm.

Repository located at: https://github.com/gonzoleeman/open-isns

-- 
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

[The Lee-Man]

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.

[PATCH] open-isns: reliably get your own IP address

[The Lee-Man]

Hi All:

I recently patched open-isns. It had an issue getting it's
own IP address reliably.

It was using getsockname(), but the length it was passing
it was not initialized, as it is supposed to be.

On x86 this seemed to be working anyway, though no
telling what memory might be corrupted. But on other
architectures it seemed to fail as often as it succeeded.

The attach patch has already been added to the open-isns
repository at github.com:gonzoleeman/open-isns.git.

-- 
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.
>From 7b4fd0cb8384312e3718953ad1c71ad7f03cbd62 Mon Sep 17 00:00:00 2001
From: Lee Duncan 
Date: Thu, 3 Sep 2015 16:03:29 -0700
Subject: [PATCH] Ensure we can reliably get our local IP address.

Getting local IP address failed intermittently because
we were not setting the "length" variable before calling
getsockname() in isns_socket_get_local_addr(), which
was called any time we were not using "--local".
---
 socket.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/socket.c b/socket.c
index 4f16fe68b7b5..69dc028f6e92 100644
--- a/socket.c
+++ b/socket.c
@@ -2248,6 +2248,7 @@ isns_socket_get_local_addr(const isns_socket_t *sock,
 
 	if (sock->is_desc < 0)
 		return 0;
+	alen = sizeof(*addr);
 	if (getsockname(sock->is_desc,
 			(struct sockaddr *) addr, ) < 0) {
 		isns_error("getsockname: %m\n");
-- 
2.1.4

Re: [PATCH 1/1] add systemd unit for automatic target login

[The Lee-Man]

Hi Christian:

I apologize: I should have posted it before, but I have a similar service 
file that
we have been using successfully on SUSE now for a while. It's similar to 
yours
but has a few differences. I will post it shortly as a patch, for 
consideration
by the list.

On Thursday, September 10, 2015 at 8:20:17 AM UTC-7, Christian Hesse wrote:
>
> Signed-off-by: Christian Hesse  
> --- 
>  etc/systemd/iscsi-login.service | 12  
>  1 file changed, 12 insertions(+) 
>  create mode 100644 etc/systemd/iscsi-login.service 
>
> diff --git a/etc/systemd/iscsi-login.service 
> b/etc/systemd/iscsi-login.service 
> new file mode 100644 
> index 000..72d80dc 
> --- /dev/null 
> +++ b/etc/systemd/iscsi-login.service 
> @@ -0,0 +1,12 @@ 
> +[Unit] 
> +Description=Open-iSCSI login to automatic targets 
> +Documentation=man:iscsid(8) man:iscsiadm(8) 
> +After=iscsid.service iscsid.socket 
> + 
> +[Service] 
> +Type=oneshot 
> +ExecStart=/usr/bin/iscsiadm -m node --loginall=automatic 
> +ExecStop=/usr/bin/iscsiadm -m node --logoutall=automatic 
> + 
> +[Install] 
> +WantedBy=multi-user.target 
> -- 
> 2.5.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+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.

systemd files for open-iscsi

[The Lee-Man]

A recent patch submission by Christian Hesse to supply an "iscsi login 
service"
for systemd spurred me to share the systemd files currently being used by
SUSE, since these may help others (like Christian).

In the open-iscsi repository, there are only two systemd files:

iscsid.socket -- the socket-activiation service for iscsid
iscsid.service -- how to start/stop iscsid

Our iscsid.service file is slightly different from what is in the 
open-iscsi repository,
so here is a context diff:

>> cut here <<---
[Unit]
Description=Open-iSCSI
Documentation=man:iscsid(8) man:iscsiuio(8) man:iscsiadm(8)
DefaultDependencies=no
After=network.target iscsiuio.service
Before=remote-fs-pre.target

[Service]
Type=simple
ExecStart=/sbin/iscsid -f
ExecStop=/sbin/iscsiadm -k 0 2

[Install]
WantedBy=multi-user.target
Also=iscsid.socket
>> cut here <<---

Differences from current repository file:

- Service type changed to simple, as it's more reliable
- our daemon is in /sbin instead of /usr/sbin
- specifically mention the socket file
- several changes to support iSCSI volumes at boot time:
- no default dependencies (or it starts too late)
- don't need all of the "After*"s
- add a "Before*"

Perhaps some of these would be generally useful? And I expect
that the RedHat version is slightly different. Anyone interested in
posting it, so we might come up with a common solution, as much
as possible?

Note: we also enable, by default, the iscsid.socket service, so that
iscsid can be started any time after installation simply by trying
to access it.

Next, our distro has a service file for iscsi login/logout service. We
called it "iscsi.service", and here's the whole service file:

>> cut here <<---
[Unit]
Description=Login and scanning of iSCSI devices
Documentation=man:iscsiadm(8) man:iscsid(8)
After=network.target network-online.target iscsid.service
ConditionPathExists=/etc/iscsi/initiatorname.iscsi

[Service]
Type=oneshot
ExecStart=-/sbin/iscsiadm -m node --loginall=automatic
ExecStop=/sbin/iscsiadm -m node --logoutall=automatic
SuccessExitStatus=21
RemainAfterExit=true

[Install]
WantedBy=remote-fs.target
>> cut here <<---

You can see there are some differences from the patch proposed by Christian
recently:
- you do not need to say "after" iscsid.socket
- after network target, since we need it running and online
- no need to start if there is no initiator name
- make the "start" ignore errors, else the service thinks it is not running
  if there are no targets at startup time, even if they've been added
- ignore a return status of 21, which just means not all target logins
  worked
- remain after started, so the service thinks it is running even
  after the one shot

And, lastly, we also have two service files for iscsiuio. Here is 
iscsiuio.socket:
>> cut here <<---
[Unit]
Description=Open-iSCSI iscsiuio Socket
Documentation=man:iscsiuio(8)

[Socket]
ListenStream=@ISCSID_UIP_ABSTRACT_NAMESPACE

[Install]
WantedBy=sockets.target
>> cut here <<---

And iscsiuio.service:
>> cut here <<---
[Unit]
Description=iSCSI UserSpace I/O driver
Documentation=man:iscsiuio(8)
DefaultDependencies=no
Conflicts=shutdown.target
Requires=iscsid.service
BindTo=iscsid.service
After=network.target
Before=remote-fs-pre.target iscsid.service

[Service]
Type=forking
PIDFile=/var/run/iscsiuio.pid
ExecStart=/sbin/iscsiuio

[Install]
WantedBy=multi-user.target
>> cut here <<---

Note that the iscsiuio service has not gotten nearly as much testing and 
tweaking
as the iscsid and iscsi files have, so YMMV. But these are what we currently
have.

I will be glad to supply some or all of these changes as patches, if there 
is interest.
Of course there was a small change in the iscsiuio daemon, as well, to 
support socket
activation, which is another patch I'd be glad to supply if needed.


-- 
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: [PATCH v3 0/2] open-iscsi: Ping support in iscsiuio

[The Lee-Man]

On Tuesday, November 17, 2015 at 10:04:44 AM UTC-8, Mike Christie wrote:
>
> On 09/18/2015 05:38 AM, adheer.cha...@qlogic.com  wrote: 
> > From: Adheer Chandravanshi  
> > 
> > Mike, 
> > 
> > This is patchset v3 to add ping support in iscsiuio. 
> > Please review and apply following patches to open-iscsi.git tree at your 
> earliest convenience. 
> > 
> > Changes with respect to v2 patchset: 
> >  * Corrected the logic for ping status message 
> >  * Change the transport callout name to exec_ping 
> > 
> > Adheer Chandravanshi (2): 
> >   iscsid: Changes to support ping through iscsiuio 
> >   iscsiuio: Add ping support through iscsiuio 
> > 
>
> Do you distro people have any comments? 
>
> My only concern is that if this is the first command run for the iface, 
> the ping will fail. The user has to retry. I thought it might cause 
> confusion. For normal session and discovery session login, we retry the 
> same error for the user. 
>
> The options on the table are: 
>
> 1. Add the apply op command. The user will have to run this before 
> running ping. 
>
> 2. Add the apply op, and add a udev rule so when the module is loaded we 
> can have it run automatically. 
>
> If we go this route, do distro people want us to get the rule in udev or 
> carry it in the iscsi package and install it. 
>
> 3. Have the ping command retry like is done with normal/discovery 
> session login. 
>

I strongly prefer #3. Both #1 and #2 are a departure from the way the other 
commands work. 

-- 
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: iscsistart takeover vs iface names

[The Lee-Man]

Mike: I know you've been busy. Any progress on this? Can I help, as I have 
the same issue?

On Thursday, October 8, 2015 at 2:48:30 PM UTC-7, Mike Christie wrote:
>
> On 10/08/2015 04:10 PM, Ferenc Wagner wrote: 
> > Mike Christie > writes: 
> > 
> >> > On 10/7/15, 1:37 AM, Ferenc Wagner wrote: 
> >> > 
> >>> >> In a pristine system (iscsistart only, no targets configured by 
> >>> >> iscsiadm) I only get two sessions (with short interfaces names). 
>  With 
> >>> >> an older open-iscsi version I could then add the four needed node, 
> and 
> >>> >> after login iscsid took over the two from iscsistart and also 
> started 
> >>> >> the two other.  Now, that iscsid uses long interface names, it 
> creates 
> >>> >> four new sessions and leaves the two from iscsistart unmanaged. 
>  Than 
> >> > 
> >> > How do you know they are unmanaged by iscsid? Is the iscsid session 
> >> > state in the iscsiadm -m session -P 1 info showing: 
> >> > 
> >> > Internal iscsid Session State: Unknown 
> > Maybe I was wrong on this point.  After an iscsistart -b in the 
> > initramfs, but with no ifaces or nodes configured later: 
>
> No problem. I think I fully understand the problem. I am working on a 
> patch. I messed up the firmware on my card, so I cannot access the boot 
> setup any more here, but am looking for one in the red hat lab. 
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: iscsistart takeover vs iface names

[The Lee-Man]

Hi Mike:

I tested your patch, and it fixes the issue I was seeing with Emulex cards
using the be2iscsi driver.

I thought about the upgrade implications while testing on this system,
and I discussed my results with Hannes. It looks like there should
not be an upgrade issue. Instead, a system being upgraded with
be2iscsi would end up with three interface files for each interface:
the original interface file, named:

* be2iscsi.MAC_ADDR  -- the original interface file
* be2iscsi.MAC_ADDR.ipv4.0 -- a new interface file for IPv4
* be2iscsi.MAC_ADDR.ipv6.0 -- a new interface file for IPv6

So I would say go ahead and submit this patch. :)

On Friday, May 27, 2016 at 2:46:31 PM UTC-7, Mike Christie wrote:
I think we can do something like the attached compile tested only patch 
which has the boot code use the same iface name format as the normal setup. 

My concern was compat support. The patch will use whatever the kernel 
supports, and so it should just work for boot if you are using 
iscsistart or "iscsiadm -m fw -l", but I am not sure if during a upgrade 
things will work with mismatch of old and new kernel and tools and old 
stored /etc/ifaces and how distros were using the tools. 

I got busy with day time work stuff, and I killed my card (updated the 
fw and now it only supports networking instead of iscsi and I cannot 
covert back) so I was not able to go over all the combos. If you can 
test it out it and think of the SUSE upgrade scenarios you guys support 
it would help. 


On 05/27/2016 01:13 PM, The Lee-Man wrote: 
> Mike: I know you've been busy. Any progress on this? Can I help, as I 
> have the same issue? 
> 
> On Thursday, October 8, 2015 at 2:48:30 PM UTC-7, Mike Christie wrote: 
> 
> On 10/08/2015 04:10 PM, Ferenc Wagner wrote: 
> > Mike Christie <m*@cs.wisc.edu> writes: 
> > 
> >> > On 10/7/15, 1:37 AM, Ferenc Wagner wrote: 
> >> > 
> >>> >> In a pristine system (iscsistart only, no targets configured by 
> >>> >> iscsiadm) I only get two sessions (with short interfaces 
> names). With 
> >>> >> an older open-iscsi version I could then add the four needed 
> node, and 
> >>> >> after login iscsid took over the two from iscsistart and also 
> started 
> >>> >> the two other. Now, that iscsid uses long interface names, 
> it creates 
> >>> >> four new sessions and leaves the two from iscsistart 
> unmanaged. Than 
> >> > 
> >> > How do you know they are unmanaged by iscsid? Is the iscsid 
> session 
> >> > state in the iscsiadm -m session -P 1 info showing: 
> >> > 
> >> > Internal iscsid Session State: Unknown 
> > Maybe I was wrong on this point. After an iscsistart -b in the 
> > initramfs, but with no ifaces or nodes configured later: 
> 
> No problem. I think I fully understand the problem. I am working on a 
> patch. I messed up the firmware on my card, so I cannot access the boot 
> setup any more here, but am looking for one in the red hat lab. 
> 
> -- 
> 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 
> <mailto:open-iscsi+unsubscr...@googlegroups.com>. 
> To post to this group, send email to open-iscsi@googlegroups.com 
> <mailto:open-iscsi@googlegroups.com>. 
> Visit this group at https://groups.google.com/group/open-iscsi. 
> For more options, visit https://groups.google.com/d/optout. 

Hi Mike:

I tested your patch, and it fixes the issue I was seeing with Emulex cards
using the be2iscsi driver.

I thought about the upgrade implications while testing on this system,
and I discussed my results with Hannes. It looks like there should
not be an upgrade issue. Instead, a system being upgraded with
be2iscsi would end up with three interface files for each interface:
the original interface file, named:

  * be2iscsi.MAC_ADDR-- the original interface file
  * be2iscsi.MAC_ADDR.ipv4.0   -- a new interface file for IPv4
  * be2iscsi.MAC_ADDR.ipv6.0  -- a new interface file for IPv6


On Friday, May 27, 2016 at 2:46:31 PM UTC-7, Mike Christie wrote:
>
> I think we can do something like the attached compile tested only patch 
> which has the boot code use the same iface name format as the normal 
> setup. 
>
> My concern was compat support. The patch will use whatever the kernel 
> supports, and so it should just work for boot if you are using 
> iscsistart or "iscsiadm -m fw -l", but I am not sure if during a upgrade 
> things will work with mismatch of old and new kernel and tools and old 
> stored /etc/ifaces and how distro

Re: sysfs compatibility during logouts and could not read session info errors

[The Lee-Man]

I'm guessing that all of these issues have to do with the inherent 
asynchronous nature of sysfs. The time between an event happening and the 
sysfs data representing it is not zero, and when the system becomes busy 
this time delta can be large enough so that assumptions in the code start 
breaking down.

As long as we rely so heavily on sysfs we will continue to have problems, 
especially on highly-loaded system, or systems with huge numbers of 
targets/LUNs. Even better caching will not help in this case. The only 
thing that might mitigate this issue IMHO, again assuming we continue to 
use sysfs, is to build in reasonable retries in every sysfs access.

Chris, is your research on large number of targets lead you to believe 
there is a better approach?


On Tuesday, June 21, 2016 at 3:20:12 PM UTC-7, Anand Subramanian wrote:
>
> Hi All,
>
> We have a large number of iscsi logins and logouts in our setup. During 
> the logouts we see the following messages. Eventually the logouts succeed 
> after retries but does this point to some more fundamental mismatch which 
> should be corrected or can these be ignored?
>
> 2016-06-19 13:55:12 INFO miutils.py:2255 Executed: sudo iscsiadm --m node 
> --logout --target 
> iqn.2010-06.com.xyz:7b1652d2-4185-4b01-97cd-8add64a97c37-tgt0
>
> 2016-06-19 13:55:12 INFO minutils.py:2259 stderr: iscsiadm: Could not 
> lookup devpath for session174. Possible sysfs incompatibility.
>
>
> *iscsiadm: Could not lookup devpath for session176. Possible sysfs 
> incompatibility.*
>
>
> We are using open-iscsi-2.0-872-rc4-bnx2i on CentOS with Linux version 
> 3.10.0-229.26.2.el6
>
>
> Based on past ML posts, I have checked "whereis iscsid" and iscsiadm and 
> they all seem to be of the same bitness (x86_64).
>
>
> We do a fairly large number of logins and logouts and one of the things to 
> try out for improving performance would be Chris' patches from another 
> recent thread. Will give it a shot based on our open-iscsi versions for the 
> patch and see how that goes.
>
>
> But the above messages during logouts are seen as well as some other 
> messages during logins
>
>
> 2016-06-19 13:56:18 INFO minutils.py:2255 Executed: sudo iscsiadm --m node 
> --targetname=iqn.2010-06.com.xyz:de49c23b-76c2-422d-8659-74ad8a47e864-tgt3 
> --login --portal 10.4.81.16
>
> 2016-06-19 13:56:18 INFO minutils.py:2259 stderr: *iscsiadm: could not 
> read session targetname: 5*
>
> iscsiadm: could not find session info for session17
>
>
> TIA for any pointers/inputs.
>
>
> Regards,
>
> Anand
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: login fail

[The Lee-Man]

You really need to supply more information than this.

It looks like you don't have your target set up correctly. What type of 
target are you using (and on what platform)? Can you share it's 
configuration?

On Wednesday, June 22, 2016 at 1:07:14 AM UTC-7, 陳德安 wrote:
>
>
> Hi,
>
> I have the question at login of iSCSI
>
> console:
>
> iscsiadm: initiator reported error (13 - daemon access denied)
> iscsiadm: Could not log into all portals
>
> Could anyone tell me the reason?
>
> Thanks for your help.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

open-isns updated to version v0.96

[The Lee-Man]

Several updates have been recently to open-isns
(many thanks to Christian Seiler), and as a result
I've updated the version to v0.96.

Available at https://github.com/gonzoleeman/open-isns/releases/tag/v0.96.

Note: It is my plan "some time soon" to move open-isns from
being a "personal" project on github to being under the
"open-iscsi" group. As with the open-iscsi change,
it will just mean a different URL, but the code and
process will remain the same.

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Do you prefer pull requests or patches submitted?

[The Lee-Man]

Hi Mike:

I see you have taken some pull requests using the github issue/pull-request 
mechanism. Do you prefer this over the mailing list? I know I kind of 
prefer it, myself, from both directions, since it makes the workflow a 
touch easier and faster. What's your preference?
-- 
Lee Duncan

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] Build system: sort object file lists

[The Lee-Man]

On Saturday, February 13, 2016 at 3:30:13 PM UTC-8, Mike Christie wrote:

> >Lee and Chris, 
> >
> >The patch seems fine to me. It will not break SUSE or Red Hat build 
> >stuff will it? 
>

I have no objection. I personally prefer Makefile targets to be explicitly 
listed in the Make file, in which case they build would also be repeatable. 
But sorting the wildcard-filled file list is fine with me.

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: open-iscsi Ping timeout error.

[The Lee-Man]

Hi:

It seems like your backend is getting busy and not replying in time when it 
gets very busy. You can disable the NOOP, or you can lengthen its interval, 
I believe.

If there is a bug, it would be in the kernel target subsystem. Have you 
tried the target-devel @ vger kernel mailing list?

On Friday, May 13, 2016 at 9:52:46 AM UTC-7, Zhengyuan Liu wrote:
>
> Hi everyone:
> I create a target using fileio as the backend storage on ARM64 server. The 
> initiator reported some errors showed bellow  while perform iozone test.
>
> [178444.145679]  connection14:0: ping timeout of 5 secs expired, recv 
> timeout 5, last rx 4339462894, last ping 4339464146, now 4339465400
> [178444.145706]  connection14:0: detected conn error (1011)
> [178469.674313]  connection14:0: detected conn error (1020)
> [178504.420979]  connection14:0: ping timeout of 5 secs expired, recv 
> timeout 5, last rx 4339477953, last ping 4339479204, now 4339480456
> [178504.421001]  connection14:0: detected conn error (1011)
> [178532.064262]  connection14:0: detected conn error (1020)
> [178564.584087]  connection14:0: ping timeout of 5 secs expired, recv 
> timeout 5, last rx 4339492980, last ping 4339494232, now 4339495484
> ..
>
> I try to trace the function call of target iscsi. Then, I found the 
>  receiving  thread of target iscsi blocked at fd_execute_sync_cache -> 
> vfs_fsync_range. Further, vfs_fsync_range may takes more than 10 seconds to 
> return,while initiator Ping timeout would happened after 5 seconds.   
> vfs_fsync_range was call with the form vfs_fsync_range(fd_dev->fd_file, 0, 
> LLONG_MAX, 1) every times  which means sync all device cache. 
> So, is this a bug?
> How  does Initiator send sync_cache scsi command? 
> Does it need to sync all device cache at once?
> Any reply would be thankful.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: "iscsi-initiator-utils" cannot recognize NIC ports

[The Lee-Man]

On Thursday, March 17, 2016 at 6:32:34 AM UTC-7, z*@gmail.com wrote:
>
> Hi!
>
> I'm in trouble with "iscsi-initiator-utils" and my iscsi target.
> I have a Dell T420 server and a Dell SCv2000 storage.The server is 
> installed with two NICs and "iscsi-initiator-utils" software.
> The SCv2000 is the target I want to connect to.Each NIC has two 
> ports,however, the target seems to recognize only one port.
>
> After the installation of "iscsi-initiator-utils" , a file named 
> initiatorname.iscsi are created.In my view,iscsi will assign an initiator 
> name for the recognized port.
> There is only one initiatorname in my file rather than four.I attemptted 
> to add initiatornames into it,but it was of no use.
>

There is only one initiator name for your host, not one for each NIC or 
port.
 

>
> The initiator and the target were well configured once, but one of the two 
> NICs has some quality problems.I changed a new one  and configured them as 
> before,
> they crashed.I don't know what to do next.Can you help me?
> Thx.
>

Now there's a crash?

Can you share the iscsiadm command you are using? Please run it with "-d5" 
and share the result. 

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Using all 24-bits of the ISID

[The Lee-Man]

When we made the most recent changes to open-iscsi:

  "make use of all 24 bits of ISID qualifier space"

we agreed it would be a "good thing" to modify the kernel
to use the "id" routines instead of an atomic int.

I created a set of patches and submitted them, and they
got comments, but the current version has sat for a month
without comment.

I'd really like to either get these changes into the kernel
if we want them there.

Can anyone on the list review them, please, if they get a chance?

On LKML or linux-scsi, the subject is:

  "Re: [PATCHv3 0/2] target: make location of /var/targets configurable"

Thank you.
-- 
Lee Duncan

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Segfaults from iscsiuio (iscsiuio/src/unix/nic_nl.c)

[The Lee-Man]

On Thursday, July 28, 2016 at 2:16:12 AM UTC-7, Frank Fegert wrote:
>
> Hello all, 
>

Hi Frank. 

>
> disclaimer: i'm not a programmer, so the following might be utterly 
> and completely wrong ;-) 
>
> TL;DR: i'm getting segfaults from iscsiuio upon any target login. 
> Specifically this happens in iscsiuio/src/unix/nic_nl.c. Debugging 
> this lead me to believe this is a case of trying to unlock a not 
> locked mutex. A quick and dirty hack which works around this is 
> available here: 
>   
> https://github.com/frank-fegert/open-iscsi/commit/9f770f9eb0f302d146d455f1d68648e2d0172eb6
>  
>
> There is probably room for a proper fix (e.g. counter on the number of 
> locks?), which considers the semantics of the whole code. 
>

I looked at your suggested fix, and I think it's almost correct.

The caller should indeed have the mutex locked when calling
pthread_cond_wait. It's probably just luck this hasn't blown up before.

But I think it just needs one tweak. You need to call
pthread_mutex_unlock() in the error case, i.e. in the
"rc != 0" case, before calling LOG_ERR().

Can you submit a patch or pull request updated with this
change?

>
>
> The longer explanation: 
>
> My setup involves 6 Dell M630 hosts (host1, host{5,6,7,8,9}), all with 
> BCM57810 iSOEs. BCM57810 firmware, software (Debian 8) and targets are 
> exactly the same on all hosts. I'm using the Debian open-iscsi package, 
> which is rebuild in order to include iscsiuio and has the changes up to 
> Git commit 0fa43f29 - but excluding c6d1117b and 76832662 (externalization 
> of the open-isns code) - backported. The only difference is, host1 has 
> Intel E5 v3 CPUs, host{5,6,7,8,9} have Intel E5 v4 CPUs. 
>
> On host1 everything works fine, iscsiuio runs as expected, access to 
> targets is working flawlessly. 
> On host{5,6,7,8,9} i'm getting segfaults like the one in the example 
> shown below, while trying to log in to any target. 
>
> Searching for "__lll_unlock_elision" in conjunction with "pthread_*" 
> led me to the following resources: 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574 
>   https://lwn.net/Articles/534758/ 
>
> which are pointing towards a CPU (Broadwell and Skylake) specific pro- 
> blem when not carefully using mutexes. The general opinion from there 
> and other related bug reports seems to be, that the application be- 
> haviour should be changed, in order to fix such an issue. 
>
> Tracking this issue further down i ended up in the function "nl_process_ 
> handle_thread" in iscsiuio/src/unix/nic_nl.c and specifically here: 
>
> 486 rc = pthread_cond_wait(>nl_process_cond, 
> 487>nl_process_mutex); 
>
> From the pthread_cond_wait manpage: 
>   The pthread_cond_timedwait() and pthread_cond_wait() functions shall 
>   block on a condition variable. They shall be called with mutex locked 
>   by the calling thread or undefined behavior results. 
>
> On the first pass of the loop, this constraint seems to be true. At 
> the end of the loop at: 
>
> 499 pthread_mutex_unlock(>nl_process_mutex); 
>
> the mutex is then unlocked. Thus - if i understand the code right - 
> the above constraint is no longer met on the subsequent passes of the 
> loop. On Intel E5 v3 this seemed to be tolerated and without any impact. 
> But on Intel E5 v4 (and other CPUs implementing HLE and RTM) this IMHO 
> causes the observed segfault. 
>
> Could someone more familiar with mutex handling in phtreads and/or the 
> semantics of the iscsiuio code please take a look at this? I'd be inter- 
> ested if my analysis is correct and whether my quick'n'dirty fix has 
> any major side-effects. And - of course - what a proper fix for the ob- 
> served segfault would look like ;-) 
>
> Thanks & best regards, 
>
> Frank 
>
>
> host5:~# gdb /sbin/iscsiuio 
> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 
> Copyright (C) 2014 Free Software Foundation, Inc. 
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html> 
> This is free software: you are free to change and redistribute it. 
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying" 
> and "show warranty" for details. 
> This GDB was configured as "x86_64-linux-gnu". 
> Type "show configuration" for configuration details. 
> For bug reporting instructions, please see: 
> . 
> Find the GDB manual and other documentation resources online at: 
> . 
> For help, type "help". 
> Type "apropos word" to search for commands related to "word"... 
> Reading symbols from /sbin/iscsiuio...(no debugging symbols found)...done. 
>
> (gdb) run -d 4 -f 
> Starting program: /sbin/iscsiuio -d 4 -f 
> [Thread debugging using libthread_db enabled] 
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 
> INFO  [Wed Jul 27 10:01:45 2016]Initialize logger using log file: 
> /var/log/iscsiuio.log 
> INFO  [Wed Jul 27 10:01:45 

Chris Leech, please contact me

[The Lee-Man]

Apologies for this broadcast email, but ...

Chris Leech, please contact me.

I sent you email directly, but your SPAM filter may have eaten it.

lduncan at suse dot com

Thanks.
--
Lee

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable - Message from syslogd@localhost

[The Lee-Man]

You are getting an empty error message? That alone sounds like an issue.
Are there any other error messages in your messages file during that same 
time?

What OS and version of open-iscsi are you using?

On Friday, September 9, 2016 at 2:27:16 PM UTC-7, Vimol Kshetrimayum wrote:
>
> I am getting sometime the following message in the console. 
>
> -
> Message from syslogd@localhost at Sep  7 14:30:13 ...
> iscsid:
> -
>
> Is there any way to disable broad casting this message in the console?
>
> Would it be possible to control it from rsyslog.conf. 
> If yes, how I can do it ?
>
> Regards,
> -Vimol
>
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

[The Lee-Man]

Christoph Hellwig suggested we do away with the open-iscsi google group 
(this group) and use linux-scsi.

Any thoughts on this? (removed others on the cc list).

On Monday, September 26, 2016 at 3:26:36 PM UTC-7, Lee Duncan wrote:
>
> Chris Leech and I are taking over as open-iscsi maintainers. 
>
> Changes since v1: 
>  * Updated URL to open-iscsi.com 
>  * Removed git repository, since code in tree 
> --- 
>  MAINTAINERS | 6 +++--- 
>  1 file changed, 3 insertions(+), 3 deletions(-) 
>
> diff --git a/MAINTAINERS b/MAINTAINERS 
> index 01bff8ea28d8..81384a2562e7 100644 
> --- a/MAINTAINERS 
> +++ b/MAINTAINERS 
> @@ -6448,10 +6448,10 @@ S:Maintained 
>  F:drivers/firmware/iscsi_ibft* 
>   
>  ISCSI 
> -M:Mike Christie  
> +M:Lee Duncan  
> +M:Chris Leech  
>  L:open-iscsi@googlegroups.com 
> -W:www.open-iscsi.org 
> -T:git git://
> git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git 
> +W:www.open-iscsi.com 
>  S:Maintained 
>  F:drivers/scsi/*iscsi* 
>  F:include/scsi/*iscsi* 
> -- 
> 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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: version 2.0.874 tagged

[The Lee-Man]

Thanks Chris!

On Thursday, September 29, 2016 at 11:42:44 AM UTC-7, Chris Leech wrote:
>
> Hi all, 
>
> There's been a lot of requests for an overdue tagged release with a new 
> version.  I've gone ahead and done that on github, creating version 
> 2.0.874.  I merged a few typo fixes, updated URLs and version numbers, 
> but there shouldn't be any surprises from what's been on the development 
> head for a while now. 
>
> Thanks, 
> Chris 
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: How to encrypt password store in nodes dir

[The Lee-Man]

There is no option to encrypt the password and storing in that format.

On Friday, September 16, 2016 at 5:24:46 PM UTC-7, Vimol Kshetrimayum wrote:

> The "iscsiadm -m discoverydb -p  -t st -o update -n 
> discovery.sendtargets.auth.password -v ", command update the 
> password and store the password in text file.
>
>
>
> Is there any option to encrypt the password and store?
>
>
> Regards,
> -Vimol
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: When is the next release of open-iscsi?

[The Lee-Man]

Yes, this is the correct forum. :)

On Thursday, September 15, 2016 at 10:28:55 PM UTC+2, Raghu Murugesan wrote:
>
> Hi All,
>  
> When in next version of open-iscsi planning to be released?
>
> Am I posting this question in the right forum?
>
> if there is a email thread where this topic is already being discussed, 
> please tag tag me/ forward me that thread.
>
> Thank You
>
> - Raghu Murugesan
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

open-isns: BUG: Discovery Domain membership duplicated when restoring from disc

[The Lee-Man]

I recently found and fixed a bug in open-isns:

commit d6004bf7358a3ac3a040b475cdd96fc243b118f8
Author: Lee Duncan 
Date:   Wed Oct 26 13:54:33 2016 -0700

Fix DD member doubling when restoring from DB.

Fix issue where a restore of DD members from
disc, at startup time, was getting duplicdate
entries for each member. The membership bit for
each object must be set when it is read, so
that duplicate objects can be detected in time
to be rejected.

At the same time, I fixed a few cosmetic issues and updated the
version to 0.97. This new version includes Chris' recent changes
to support openSSL 1.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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: iscsi: make mutex for target scanning and unbinding per-session

[The Lee-Man]

On Monday, November 7, 2016 at 11:22:23 AM UTC-7, Chris Leech wrote:
>
> Currently the iSCSI transport class synchronises target scanning and 
> unbinding with a host level mutex.  For multi-session hosts (offloading 
> iSCSI HBAs) connecting to storage arrays that may implement one 
> target-per-lun, this can result in the target scan work for hundreds of 
> sessions being serialized behind a single mutex.  With slow enough 
> response times, this can cause scan requests initiated from userspace to 
> block on the mutex long enough to trigger 120 sec hung task warnings. 
>
> I can't see any reason not to move this to a session level mutex and let 
> the target scans run in parallel, speeding up connecting to a large 
> number of targets.  Note that as iscsi_tcp creates a virtual host for 
> each session, software iSCSI is effectively doing this already. 
>

I understood the reason for this mutex was to protect against the case
where there are multiple paths to a target. In such cases, you can get
simultaneous access to sysfs attributes (files), which can cause errors,
i.e. two threads trying to write an attribute at the same time, or one
changing an attribute while another reads or removes it.

I worry that changing it will not address those issues.

[Side note: we *really* need a test suite that somehow includes
 cases like this.]

>
> Signed-off-by: Chris Leech  
> --- 
>  drivers/scsi/scsi_transport_iscsi.c | 19 ++- 
>  include/scsi/scsi_transport_iscsi.h |  2 +- 
>  2 files changed, 7 insertions(+), 14 deletions(-) 
>
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c 
> index 42bca61..83c90fa 100644 
> --- a/drivers/scsi/scsi_transport_iscsi.c 
> +++ b/drivers/scsi/scsi_transport_iscsi.c 
> @@ -1568,7 +1568,6 @@ static int iscsi_setup_host(struct 
> transport_container *tc, struct device *dev, 
>   
>  memset(ihost, 0, sizeof(*ihost)); 
>  atomic_set(>nr_scans, 0); 
> -mutex_init(>mutex); 
>   
>  iscsi_bsg_host_add(shost, ihost); 
>  /* ignore any bsg add error - we just can't do sgio */ 
> @@ -1789,8 +1788,6 @@ static int iscsi_user_scan_session(struct device 
> *dev, void *data) 
>  { 
>  struct iscsi_scan_data *scan_data = data; 
>  struct iscsi_cls_session *session; 
> -struct Scsi_Host *shost; 
> -struct iscsi_cls_host *ihost; 
>  unsigned long flags; 
>  unsigned int id; 
>   
> @@ -1801,10 +1798,7 @@ static int iscsi_user_scan_session(struct device 
> *dev, void *data) 
>   
>  ISCSI_DBG_TRANS_SESSION(session, "Scanning session\n"); 
>   
> -shost = iscsi_session_to_shost(session); 
> -ihost = shost->shost_data; 
> - 
> -mutex_lock(>mutex); 
> +mutex_lock(>mutex); 
>  spin_lock_irqsave(>lock, flags); 
>  if (session->state != ISCSI_SESSION_LOGGED_IN) { 
>  spin_unlock_irqrestore(>lock, flags); 
> @@ -1823,7 +1817,7 @@ static int iscsi_user_scan_session(struct device 
> *dev, void *data) 
>  } 
>   
>  user_scan_exit: 
> -mutex_unlock(>mutex); 
> +mutex_unlock(>mutex); 
>  ISCSI_DBG_TRANS_SESSION(session, "Completed session scan\n"); 
>  return 0; 
>  } 
> @@ -2001,26 +1995,24 @@ static void __iscsi_unbind_session(struct 
> work_struct *work) 
>  struct iscsi_cls_session *session = 
>  container_of(work, struct iscsi_cls_session, 
>   unbind_work); 
> -struct Scsi_Host *shost = iscsi_session_to_shost(session); 
> -struct iscsi_cls_host *ihost = shost->shost_data; 
>  unsigned long flags; 
>  unsigned int target_id; 
>   
>  ISCSI_DBG_TRANS_SESSION(session, "Unbinding session\n"); 
>   
>  /* Prevent new scans and make sure scanning is not in progress */ 
> -mutex_lock(>mutex); 
> +mutex_lock(>mutex); 
>  spin_lock_irqsave(>lock, flags); 
>  if (session->target_id == ISCSI_MAX_TARGET) { 
>  spin_unlock_irqrestore(>lock, flags); 
> -mutex_unlock(>mutex); 
> +mutex_unlock(>mutex); 
>  return; 
>  } 
>   
>  target_id = session->target_id; 
>  session->target_id = ISCSI_MAX_TARGET; 
>  spin_unlock_irqrestore(>lock, flags); 
> -mutex_unlock(>mutex); 
> +mutex_unlock(>mutex); 
>   
>  if (session->ida_used) 
>  ida_simple_remove(_sess_ida, target_id); 
> @@ -2053,6 +2045,7 @@ iscsi_alloc_session(struct Scsi_Host *shost, struct 
> iscsi_transport *transport, 
>  INIT_WORK(>unbind_work, __iscsi_unbind_session); 
>  INIT_WORK(>scan_work, iscsi_scan_session); 
>  spin_lock_init(>lock); 
> +mutex_init(>mutex); 
>   
>  /* this is released in the dev's release function */ 
>  scsi_host_get(shost); 
> diff 

Re: why certain function name prefix of “_ _” (double underscore)

[The Lee-Man]

On Tuesday, November 8, 2016 at 4:29:05 PM UTC-7, Raghu Murugesan wrote:
>
> I am reading the source code of open-iscsi. In source files, I see few 
> functions start with prefix "__". Whats the reason behind naming a function 
> with double underscore as prefix in general in C language?
>
> Example: In the file usr/iscsi_sysfs.c, the function name `static int 
> __get_host_no_from_hwaddress(void *data, struct host_info *info)`
>
> Thanks for reading the post
>
> - Raghu
>

I'm not sure if you are asking in general or specifically about this case.

In general, such naming is usually done to make it clear that routines like 
__get_host_no_from_hwaddress() are not called directory by external 
users.Also note that this function is static. This sort of naming is 
usually done, as well, to make it clear that there is an external interface 
(some name without underscores at the start) that is meant to be called 
externally and calls this function. In this case it's 
iscsi_sysfs_get_host_no_from_hwaddress().

I'm guessing (because I wasn't around back then) that the "__*" functions 
were copied from libudev at one time, but that is just a SWAG.

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: how to get iscsi target details(iqn) from device OS name programmatically at initiator side

[The Lee-Man]

On Thursday, November 10, 2016 at 11:03:09 AM UTC-7, lvpriyana...@gmail.com 
wrote:
>
> i need C/C++ library/API at initiator side which can give me the iscsi 
> target details(iqn) when i pass the OS device name or scsi-channel-lun 
> details.
>
> for example input will be "/dev/sdc" or something like "scsi12 Channel 00 
> Id 0 Lun: 0" and the output should be the corresponding target iqn .
>
>
>
> thanks in advance
>

Such information is available in the system. Try running "iscsiadm -m 
session -P3". This prints out the block device for each session. For 
example:

zsh> iscsiadm -m session -P3 | egrep 'iqn|disk'
iscsiadm -m session -P3 | egrep 'iqn|disk'
Target: iqn.2003-01.org.linux-iscsi.worklaptop.x8664:sn.36fa11d076f4 
(non-flash)
Iface Initiatorname: iqn.2005-03.org.open-iscsi:a02b9e9d4e52
Attached scsi disk sdb  State: running

I suspect you could get this information directly from sysfs yourself, if 
you want to figure out where it all resides.

You can look in usr/iscsi_sysfs.c to see what iscsiadm does to print out 
this information. 

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Antw: Re: [RFC 1/3] iscsid: Changes to support the new qedi transport

[The Lee-Man]

In this case, I'd like to see you create a "class" of transports that have 
this feature. Or perhaps it can be a field in the transport structure? I 
dislike checking against one transport, as Chris also mentioned.

On Wednesday, October 19, 2016 at 11:38:08 PM UTC-7, Javali, Nilesh wrote:
>
>  
>
>  
>
> On 20/10/16, 12:00 PM, "open-iscsi@googlegroups.com on behalf of Ulrich 
> Windl"  ulrich.wi...@rz.uni-regensburg.de> wrote:
>
>  
>
> Chris Leech  schrieb am 19.10.2016 um 19:14 in 
> Nachricht
>
> <20161019171452.iflp5nibq7yzi...@straylight.hirudinean.org>:
>
> On Wed, Oct 19, 2016 at 01:02:18AM -0400, nilesh.jav...@cavium.com wrote:
>
> From: Nilesh Javali 
>
> qedi is not attached to netdev hence avoid suppressing warnings.
>
> Signed-off-by: Manish Rangankar 
>
> Signed-off-by: Adheer Chandravanshi 
>
> Signed-off-by: Nilesh Javali 
>
> ---
>
>   usr/initiator_common.c |  2 +-
>
>   usr/transport.c| 12 
>
>   2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/usr/initiator_common.c b/usr/initiator_common.c
>
> index 1d1d822..dd3f3c4 100644
>
> --- a/usr/initiator_common.c
>
> +++ b/usr/initiator_common.c
>
> @@ -700,7 +700,7 @@ int iscsi_host_set_net_params(struct iface_rec *iface,
>
>   netdev = hinfo.iface.netdev;
>
> }
>
>   
>
> - if (net_ifup_netdev(netdev))
>
> + if (strcmp(iface->transport_name, "qedi") && net_ifup_netdev(netdev))
>
>   log_warning("Could not brining up netdev %s. Try running "
>
> "'ifup %s' first if login fails.", netdev, 
> netdev);
>
> We're not scattering transport name checks all over the code.
>
>  
>
> >>> At least the magic string should be replaced by a symbolic constant.
>
>  
>
>  
>
> Yes. We would validate netdev using new field in transport template to 
> have cleaner solution to suppress
>
> the warnings.
>
>  
>
>  
>
> Especially if this is just suppressing the warning level message, while
>
> net_ifup_netdev is probably logging an error?  This needs to be handled
>
> better.
>
> Is this really the first transport we have that wants net params set
>
> from iscsid without exposing a netdev?  This is going to be fun shaking
>
> out all the details now that there's a second user of iscsiuio.
>
>
>
> diff --git a/usr/transport.c b/usr/transport.c
>
> index 18b7704..b933c36 100644
>
> --- a/usr/transport.c
>
> +++ b/usr/transport.c
>
> @@ -114,6 +114,17 @@ struct iscsi_transport_template ocs = {
>
> .ep_disconnect= ktransport_ep_disconnect,
>
>   };
>
>   
>
> +struct iscsi_transport_template qedi = {
>
> + .name   = "qedi",
>
> + .set_host_ip  = SET_HOST_IP_REQ,
>
> + .use_boot_info= 1,
>
> + .bind_ep_required = 1,
>
> + .ep_connect = ktransport_ep_connect,
>
> + .ep_poll= ktransport_ep_poll,
>
> + .ep_disconnect= ktransport_ep_disconnect,
>
> + .set_net_config = uip_broadcast_params,
>
> +};
>
> +
>
>   static struct iscsi_transport_template *iscsi_transport_templates[] = {
>
> _tcp,
>
> _iser,
>
> @@ -123,6 +134,7 @@ static struct iscsi_transport_template 
>
> *iscsi_transport_templates[] = {
>
> ,
>
> ,
>
> ,
>
> + ,
>
> NULL
>
>   };
>
>   
>
> -- 
>
> 1.8.3.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+unsubscr...@googlegroups.com.
>
> To post to this group, send email to open-iscsi@googlegroups.com.
>
> Visit this group at https://groups.google.com/group/open-iscsi.
>
> For more options, visit https://groups.google.com/d/optout.
>
>  
>
>  
>
>  
>
>  
>
> -- 
>
> 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 https://groups.google.com/group/open-iscsi.
>
> For more options, visit https://groups.google.com/d/optout.
>
>  
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCHv2 0/2] Handle iscsid shutdown more cleanly

[The Lee-Man]

Please ignore this. I am going to post an updated version
that sorts out the "poll()" logic in iscsid_req.c, as Uli requested
with the earlier patch.

On Tuesday, November 22, 2016 at 2:44:56 PM UTC-8, The Lee-Man wrote:
>
> From: Lee Duncan <lduncan@*.com <ldun...@suse.com>> 
>
> This set of two patches addresses the issues 
> I mentioned on the mailing list recently relating 
> to how systemd can interfere with shutting down 
> the iscsid daemon. The iscsiadm command "-k" 
> can hang if the daemon is not present, when 
> running under systemd, when socket activated. 
>
> The first patch, from Hannes, modifies the IPC 
> communications so that user-level commands, like 
> iscsiadm and iscsistart, do not hang when waiting 
> for a response from the iscsid daemon by using 
> the poll() system call. This version also has a 
> couple of small bug fixes on top of the version 
> that Hannes posted recently. 
>
> The second patch modifies iscsid to treat a 
> SIGTERM just like it had received the "immediate 
> stop" command from iscsiadm (via the "-k" 
> option), simplifying the shutdown of iscsid so 
> that it no longer requires IPC communications. 
>
> Hannes Reinecke (1): 
>   Use timeout when waiting for responses from iscsid 
>
> Lee Duncan (1): 
>   iscsid: treat SIGTERM like "iscsiadm -k 0". 
>
>  usr/config.h   |  1 + 
>  usr/discovery.c| 16 +++--- 
>  usr/host.c |  2 +- 
>  usr/iscsi_sysfs.c  |  1 + 
>  usr/iscsiadm.c | 12 ++- 
>  usr/iscsid.c   | 29 +++--- 
>  usr/iscsid_req.c   | 52 
> +- 
>  usr/iscsid_req.h   | 15 +++-- 
>  usr/iscsistart.c   |  4 ++-- 
>  usr/session_info.c | 14 +++-- 
>  usr/session_info.h |  5 +++-- 
>  12 files changed, 99 insertions(+), 53 deletions(-) 
>
> -- 
> 1.8.5.6 
>
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] iBFT 'origin' is an enum, not a string

[The Lee-Man]

I have not seen any objections, so I'm going to merge the pull request on 
github for this patch.

On Saturday, November 12, 2016 at 11:50:17 AM UTC-8, The Lee-Man wrote:
>
> From: Lee Duncan <leeman.dun...@gmail.com> 
>
> A recent change, commit 4959a89f421fdebc, modified open-iscsi 
> to treat the "origin" field as an enum, not a character 
> string. But one spot was missed. 
> --- 
>  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", >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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

RFC: iscsid shutdown hangs with system when service manually killed

[The Lee-Man]

In this wonderful new world of systemd, I have an issue with stopping the 
iscsid service when the daemon has died or been killed.

My setup:
* I have an iscsid.socket unit file, which is enabled and started
* I have an iscsid.service unit file, which controls the iscsid daemon. 
This is disabled and not started

Normally, if I run a command like "iscsiadm -m discovery -t st -p 
SOME-TARGET", systemd notices that iscsiadm is trying to talk to iscsid 
through the socket, and it starts up iscsid. This is the cool part (IMHO) 
of systemd socket activation.

When I want to stop iscsid, I can just tell systemctl to do it via 
"systemctl stop iscsid", and it runs the "ExecStop=" command in the service 
unit file, which is "iscsiadm -k 0 2" before terminating the daemon 
process(es).

[NOTE: the "2" here in this command actually does nothing and is ignored, 
but I copied this from someplace else long ago, and the "2" was present 
there.]

It is of importance, in this case, that the ExecStop command actually sends 
an IPC message to the daemon (iscsid) requesting it to cleanly shut itself 
down. Herein lies the rub.

All of this works great until the daemon happens not to be running. You can 
simulate this with "kill -TERM $(pidof iscsid)" when the daemon is running. 
Now you are in a situation where systemd started the service and knows it 
is now not running, so it seems to send the ExecStop command to cleanly 
shut it down. This command hangs! It seems to be stuck in an infinite loop 
trying to send the shutdown command to the daemon, waiting for it to 
timeout, then trying again. The daemon starts up, sees an IPC error, and 
exits.

While this clearly seems like a systemd issue, I have found a workaround 
that looks clean. Well, as clean as the shutdown command is, anyway. This 
involves:

* modifying the "iscsiadm -k" command to require passing in the PID of the 
daemon to be killed
* modifying the iscsiadm to only call kill_iscsid() if positive PID is 
passed in, and that PID exists. It verifies this by sending a blank signal 
to the process.
* modifying the iscsid.service systemd unit file so that the ExecStop 
command becomes "iscsiadm -k 0 $MAINPID"

I know other distributions are having been dealing with iscsid service 
shutdown issues with systemd for a while now. Perhaps somebody else has a 
better solution?

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

open-isns: BUG: Discovery Domain membership duplicated when restoring from disc

[The Lee-Man]

Apologies. I get how the versioning works now. I hadn't updated the
version since you had added that, and I shouldn't have been more
careful.

It's fixed now. I had never actually pushed the tag for v0.97 yet,
so I tagged the latest commit, which reverts the changes to libisns.

On Friday, October 28, 2016 at 3:06:25 PM UTC-7, Christian Seiler wrote:
>
> > At the same time, I fixed a few cosmetic issues and updated the 
> > version to 0.97. 
>
> Unfortunately, that broke ABI for the shared library (if that's 
> enabled via --enable-shared), by replacing all references to 
> 0.96 in the version script with 0.97. That's not how version 
> scripts work - and if I now compile the shared library and 
> install it, all programs linked against 0.96 would immediately 
> fail to load (symbol version not found), even though nothing 
> in the code is actually incompatible. 
>
> If a new public function had been added in 0.97 one would add 
> a new section to the version script with that specific 
> function, to clearly indicate that that function was added in 
> 0.97. But as long as current functions remain compatible, 
> their version tag should _not_ change. (When I sent the 
> original pull request for the shared library support including 
> symbol versioning, I added a comment to the top of the version 
> script with some information on how the file works.) 
>
> Could you revert the libisns.vers change back to 0.96 as there 
> were no symbol changes (looking over the git changes)? And 
> maybe release 0.97a or 0.97.1 or so with that fixed? (Just a 
> new tarball/tag, there doesn't have to be a change in the 
> source code, that can still call itself 0.97, because the code 
> is still the same.) 
>
> (In general, I'd be happy to maintain the version script and 
> the shared library stuff in open-isns so you don't have to 
> care about that - I did add that and I'm probably the primary 
> user of that by means of the Debian packaging - but I would 
> need a bit of a heads-up before a release.) 
>
> Regards, 
> Christian 
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: iscsiadm --logoutall=all vs. sessions without match in node database

[The Lee-Man]

Hi Christian:

Apologies for not replying sooner.

Yes, this area of open-iscsi is a bit messy IMHO.

What about having open-iscsi update the node database entry when the TPG 
changes? I'd rather not see iscsid shutting down targets that were not 
specified.

What I would actually like to solve this problem more generally is a way to 
say "logout of all sessions except 'onboot' sessions", whether or not 
there's a node database entry. 

On Sunday, October 30, 2016 at 5:39:07 AM UTC-6, Christian Seiler wrote:
>
> Hello again, 
>
> On 10/02/2016 12:21 PM, Christian Seiler wrote: 
> > Recently there has been a bug report in Debian about -U all not 
> > logging out of all active iSCSI sessions on shutdown: 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838540 
> > 
> > I've isolated the problem, and what happens is as follows: 
> > 
> > 1. An external tool sets up a node configuration manually [1], but 
> >makes a small mistake, by not setting a target portal group tag 
> >at all, so open-iscsi will default to 1 - instead of the correct 
> >value of 257 for that target. (In the case of the bug reporter.) 
> > 
> > 2. The external tool logs in on that portal via iscsiadm. 
> > 
> > 3. The login succeeds, but either iscsid or the kernel (I'm not 
> >deep enough in the code to know exactly where that happens) 
> >figures out "hey, the actual portal target group tag is 257, 
> >so use that". Hence, login succeeds, but the node database 
> >references the wrong portal group. 
> > 
> > 4. On shutdown, iscsiadm --logoutall=all is called. The 
> >__logout_by_startup callback tries to run idbm_rec_read() on 
> >the session, that fails, so it completely skips that session. 
> > 
> > This behavior in (4) seems wrong to me in two ways: 
> > 
> >  a. If the tpgt can change after login, then the matching against 
> > the tpgt should be relaxed. 
> > 
> > i.e. first try to match the tpgt exactly, if that fails, 
> > just try to find the same match but without fixing the tpgt. 
> > That way, if a login changed the tpgt implicitly, this 
> > would still match the right config with the right session. 
> > 
> >  b. Regardless of that, there could be active iSCSI sessions 
> > without a corresponding configuration. For example, if the 
> > configuration was wiped accidentally before shutting down 
> > the session. Or someone accidentally used iscsistart on a 
> > already booted system without knowing what they were doing. 
> > In that case, would it not be better if --logoutall=all is 
> > specify to not skip that session, even if there's no match 
> > in the node database? After all, the manpage says -U all 
> > will logout of all active sessions that are NOT onboot, 
> > and it doesn't say "all sessions that have a config AND are 
> > not onboot". 
> > 
> > The counterpoint to that would be: if someone were have a 
> > setup with root on iSCSI, and the session of the root 
> > filesystem not configured in the node database at all (but 
> > rather just in some separate config used by the initramfs 
> > they were using), then the current behavior treats that as 
> > if onboot were set in that case, whereas my proposed change 
> > would be treat that as automatic or manual and -U all 
> > would also kill that. In Debian that wouldn't be a problem, 
> > as we already have logic in the shutdown script to 
> > dynamically detect the session on which the root filesystem 
> > (and potentially /usr) is located, but other distros 
> > probably don't. 
> > 
> > But maybe we could add --logoutall=reallyall or something? 
> > (Maybe with a better name?) 
> > 
> > I'm mostly interested in fixing (a), because that's what's 
> > causing the immediate problem the bug reporter is experiencing. 
> > But (b) deserves some consideration as well IMHO. 
> > 
> > Now of course, the original bug is the external tool generating 
> > a static node config with the wrong tpgt - and if open-iscsi 
> > were to simply refuse logins in the first place, I'd also be 
> > fine with that behavior. But since that's not the case (and it's 
> > very likely true that a lot of people are in some way relying on 
> > the fact that the tpgt isn't that important at login, so it's 
> > not going to be realistic to change that), and the login does 
> > succeed anyway, I think the automated logout should as well. 
> > 
> > I can work on a patch, but before I start, I'd like to hear 
> > some thoughts on this first. Thanks! 
>
> I would appreciate it if I could get some feedback on this, because 
> I would really like to see this fixed. While I'd be able and willing 
> to write a patch for that, I'd first like to hear back so I don't 
> waste time going on in a direction that'll ultimately be rejected. 
>
> Thanks! 
>
> Regards, 
> Christian 
>

-- 
You received this message because you are subscribed to the Google 

Re: [RESEND][PATCH v2 0/3] Add QLogic FastLinQ offload iSCSI driver (qedi) support

[The Lee-Man]

Nilesh:

These patches look good to me, but I'd like to hear from Chris. (And Mike, 
if he so chooses.)

I know Hannes hoped this project would *not* use iscsiuio, but I saw a 
pledge to made iscsiuio card-agnostic "some time soon".


On Tuesday, November 29, 2016 at 9:47:49 PM UTC-8, Javali, Nilesh wrote:
>
> Hi Chris, Lee, 
>
> The qedi driver support patches have been Reviewed and Acked on the SCSI 
> mailing list, 
> and we are in process of sending the final patch set, 
> http://marc.info/?l=linux-scsi=148044021432234=2 
>
> If you are ok with the open-iscsi patch series then request to Ack and 
> pull these supporting patches. 
>
> Thanks, 
> Nilesh 
>
>
> On 11/11/16, 11:47 AM, "Nilesh Javali"  > wrote: 
>
> >This patchset adds qedi driver support for QLogic FastLinQ 41000 Series 
> >Converged Network Adapters for iSCSI offload. 
> > 
> >Changes from RFC v1: 
> > 
> >Added a new field under iscsi_transport_template struct to 
> >identify netdev device. 
> > 
> >Nilesh Javali (3): 
> >  iscsid: Changes to support the new qedi transport 
> >  iscsiuio: Add support for the new qedi transport 
> >  iscsiuio: v0.7.8.3 
> > 
> > iscsiuio/README|4 +- 
> > iscsiuio/RELEASE.TXT   |   20 +- 
> > iscsiuio/configure.ac  |4 +- 
> > iscsiuio/src/unix/libs/Makefile.am |3 +- 
> > iscsiuio/src/unix/libs/cnic.c  |9 + 
> > iscsiuio/src/unix/libs/cnic.h  |2 + 
> > iscsiuio/src/unix/libs/qedi.c  | 1151 
> > 
> > iscsiuio/src/unix/libs/qedi.h  |  159 + 
> > iscsiuio/src/unix/nic.c|6 +- 
> > iscsiuio/src/unix/nic.h|1 + 
> > iscsiuio/src/unix/nic_utils.c  |  147 - 
> > iscsiuio/src/unix/nic_utils.h  |2 + 
> > iscsiuio/src/unix/options.h|1 + 
> > usr/initiator_common.c |2 +- 
> > usr/transport.c|   13 + 
> > usr/transport.h|1 + 
> > 16 files changed, 1502 insertions(+), 23 deletions(-) 
> > create mode 100644 iscsiuio/src/unix/libs/qedi.c 
> > create mode 100644 iscsiuio/src/unix/libs/qedi.h 
> > 
> >-- 
> >1.8.3.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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[The Lee-Man]

What is your setup? What OS and version are you running on, what is your 
transport, and what tape drive are you using?

On Saturday, December 10, 2016 at 9:24:33 AM UTC-8, Dave partridge wrote:
>
> I did:
>
> root@Charon:/home/amonra# mt -f /dev/st0 fsf 1
>  mt: /dev/st0: rmtioctl failed: Input/output error root
> @Charon:/home/amonra#
>
>
> The rmtioctl message appeared after about 10-15 seconds, and the iSCSI 
> target showed that the session had dropped after another 10-15 seconds.
>
> When I was returned to the command line prompt, the target showed the 
> session as connected again.
>
> During most/all of this time the forward space file operation was still 
> running.
>
> root@Charon:/home/amonra# iscsiadm -m node --targetname 
> "iqn.2008-08.com.starwindsoftware:mercury-ultrium2" --portal 
> "192.168.129.77:3260" 
> # BEGIN RECORD 2.0-873node.name = 
> iqn.2008-08.com.starwindsoftware:mercury-ultrium2
> node.tpgt = -1
> node.startup = manual
> node.leading_login = No
> iface.hwaddress = 
> iface.ipaddress = 
> iface.iscsi_ifacename = default
> iface.net_ifacename = 
> iface.transport_name = tcp
> iface.initiatorname = 
> iface.bootproto = 
> iface.subnet_mask = 
> iface.gateway = 
> iface.ipv6_autocfg = 
> iface.linklocal_autocfg = 
> iface.router_autocfg = 
> iface.ipv6_linklocal = 
> iface.ipv6_router = 
> iface.state = 
> iface.vlan_id = 0
> iface.vlan_priority = 0
> iface.vlan_state = 
> iface.iface_num = 0
> iface.mtu = 0
> iface.port = 0node.discovery_address = 192.168.129.77
> node.discovery_port = 3260
> node.discovery_type = send_targets
> node.session.initial_cmdsn = 0
> node.session.initial_login_retry_max = 8
> node.session.xmit_thread_priority = -20
> node.session.cmds_max = 128
> node.session.queue_depth = 32
> node.session.nr_sessions = 1
> node.session.auth.authmethod = None
> node.session.auth.username = 
> node.session.auth.password = 
> node.session.auth.username_in = 
> node.session.auth.password_in = 
> node.session.timeo.replacement_timeout = 120
> node.session.err_timeo.abort_timeout = 15
> node.session.err_timeo.lu_reset_timeout = 30
> node.session.err_timeo.tgt_reset_timeout = 30
> node.session.err_timeo.host_reset_timeout = 60
> node.session.iscsi.FastAbort = Yes
> node.session.iscsi.InitialR2T = No
> node.session.iscsi.ImmediateData = Yes
> node.session.iscsi.FirstBurstLength = 262144
> node.session.iscsi.MaxBurstLength = 16776192
> node.session.iscsi.DefaultTime2Retain = 0
> node.session.iscsi.DefaultTime2Wait = 2
> node.session.iscsi.MaxConnections = 1
> node.session.iscsi.MaxOutstandingR2T = 1
> node.session.iscsi.ERL = 0
> node.conn[0].address = 192.168.129.77
> node.conn[0].port = 3260
> node.conn[0].startup = manual
> node.conn[0].tcp.window_size = 524288
> node.conn[0].tcp.type_of_service = 0
> node.conn[0].timeo.logout_timeout = 15
> node.conn[0].timeo.login_timeout = 15
> node.conn[0].timeo.auth_timeout = 45
> node.conn[0].timeo.noop_out_interval = 5
> node.conn[0].timeo.noop_out_timeout = 5
> node.conn[0].iscsi.MaxXmitDataSegmentLength = 0
> node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
> node.conn[0].iscsi.HeaderDigest = None
> node.conn[0].iscsi.DataDigest = NoneThe return to the command prompt took a 
> while longer.
> node.conn[0].iscsi.IFMarker = No
> node.conn[0].iscsi.OFMarker = No
> # END RECORD
> root@Charon:/home/amonra#
>
> I'm guessing that the problem relates to iSCSI timeouts for tape devices.  
> Please can you guide me in baby steps what I need to do to resolve this 
> problem.
>
> Thanks
> Dave 
>
>
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[The Lee-Man]

I am looking at these, but I haven't gotten very far.

I've started examining the Unbuntu capture, and it seems normal so far.

On Monday, December 12, 2016 at 5:46:17 AM UTC-8, Dave partridge wrote:
>
> I just ran a Wireshark capture on the target system of the iSCSI session 
> for a Windows initiator connecting the tape and then issuing an FSF.  I 
> then did the same for the Ubuntu open-iscsi initiator.
>
> The capture for the WIndows initiator looks pretty much as I would expect 
> (given my limited knowledge of the iSCSI protocols).
>
> The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being 
> sent to the target every 15 seconds whle the FSF is being processed.  
> Definitely borked I think.
>
> Do any of the open-iscsi folk watch this forum or am I talking to myself?
>
> Dave
>
> On Sunday, December 11, 2016 at 11:55:15 AM UTC, Dave partridge wrote:
>>
>> Ubuntu 16.04.1 LTS with kernel 4.8.13.  Connected to target drive over 
>> 1GB ethernet.  Drive is HP Ultrium 460 (Ultrium 2), firmware is F63D - 
>> which is latest).
>>
>> Target is served by Starwind V8 running on Windows 10 x64
>>
>> Dave
>>
>> On Saturday, December 10, 2016 at 10:38:43 PM UTC, The Lee-Man wrote:
>>>
>>> What is your setup? What OS and version are you running on, what is your 
>>> transport, and what tape drive are you using?
>>>
>>>
>>>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: iscsistart -N skips offload NICs causing boot to fail on debian

[The Lee-Man]

On Friday, December 23, 2016 at 7:32:27 AM UTC-8, Christian Seiler wrote:
>
> On 12/22/2016 07:07 PM, Andrew Patterson wrote: 
> > I found a bnx2x card with iscsi hardware offload support. Running 
> > iscsistart -f does bring the interace up and assign an IP to it as 
> > long as OFFLOAD_BOOT_SUPPORTED is defined. However, iscsistart -b needs 
> iscsiuio 
> > running to log into a LUN, which the current debian scripts do not 
> > start (or even add to the initramfs). 
>
> So the reason why neither Ritesh nor I have added support for 
> iscsiuio in the initramfs to the Debian package is that we both 
> don't have any hardware with a corresponding network card, so 
> we are really unable to test it. 
>
 

> We'll gladly accept patches for the initramfs logic (or even 
> help writing them if you agree to test them) to get this working, 
> so please feel free to contact me, either privately or via the 
> Debian bugtracker, in this regard. 
>
> Regards, 
> Christian 
>

I have a similar issue for SUSE. I have one BNX card, but it is
an engineering prototype that actually does not work correctly.

It seems like it would behoove the card manufacturers to have
a loaner program for OS enablement. 

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[The Lee-Man]

Hi David:

I have created Issue#35 for this on github.

On Thursday, December 15, 2016 at 2:00:15 PM UTC-8, David C. Partridge 
wrote:
>
> You’re right, it is in section 8.2.  Maybe it needs to be said in 8.1.1 as 
> well?
>
>  
>
> Dave
>
>  
>
> *From:* open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] *On 
> Behalf Of *Lee Duncan
> *Sent:* 15 December 2016 19:41
> *To:* open-iscsi@googlegroups.com
> *Subject:* Re: Problem with iSCSI connected LTO-2 tape drive
>
>  
>
> On Dec 15, 2016, at 7:14 AM, david.partri...@perdrix.co.uk wrote:
>
>  
>
> Lee,
>
> It would appear that the guilty party was:
>
> node.conn[0].timeo.noop_out_interval = 5
> node.conn[0].timeo.noop_out_timeout = 5
>
> I changed both of these to 0 for the tape device and the problem went away.
>
>  
>
> Excellent.
>
>
>
>
> Please note that the README.gz for open-scsi doesn't actually say that 
> this is what you need to do to disable the NOP-out polling, so could I 
> suggest that this be stated explicitly. 
>
>  
>
> My README says, in section 8.2:
>
>  
>
> For this setup, you can turn off iSCSI pings by setting:
>
>  
>
> node.conn[0].timeo.noop_out_interval = 0
>
> node.conn[0].timeo.noop_out_timeout = 0
>
>  
>
>
>
> I must admit that I find it hard to imagine that an iSCSI target would 
> reply to a NOP-out while it was processing a command such as a tape fsf or 
> even tape erase (whose timeout is 6 * the long-timeout of 4 hours).  Should 
> perhaps the NOP-out polling be suspended while a command is being 
> processed?  Or alternatively maybe the NOP-out polling be completely 
> disabled by default with something in the README.gz file that explains WHEN 
> you might want it and how to enable it.   It's certainly clear that (at 
> least) the MS iSCSI initiator doesn't send NOP-out polls.
>
>  
>
> open-iscsi is normally used to deal with discs. When it’s used with tape 
> it’s not unusual to find bugs or design errors that we did not know were 
> present.
>
>  
>
> Perhaps a small blurb in the README about dealing with tape, suggesting 
> turning NOOP/ping off. Please feel free to post a pull request on github or 
> suggest a patch on this list.
>
>  
>
>
>
>
> Regards
> Dave
>
>  
>
>  
>
> -- 
>
> Lee Duncan
>
>  
>
> "Choice means saying no to one thing so you can say yes to another." -- 
> Dan Millman
>
>  
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "open-iscsi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/open-iscsi/ViC-za8eHdc/unsubscribe.
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: LTO-4 iSCSI performance less than expected ...

[The Lee-Man]

On Monday, March 27, 2017 at 9:03:59 AM UTC-7, 
david.partri...@perdrix.co.uk wrote:
>
> I'm connecting my Linux server to an LTO-4 tape drive over a 1 gigabit LAN 
> with very little other activity.
>
> Doing some hand waving, I guess that I should allow ten bits per byte and 
> a protocol overhead of around 40%.  That gets me to about 60MB/s which I 
> know is about half what the drive is capable of.
>
> However what I'm seeing is a consistent throughput of about 30MB/s which 
> is quite a lot slower that I'd expect.
>
> The processor is an Intel Atom D525 1.80Ghz four core processor with 4GB 
> RAM.
>
> The drive I'm backing up is a SATA SSD.   
>
> The backup is run thus:
>
> sudo mt-st -f /dev/st0l setblk 65536
> sudo dd bs=64k if=/dev/sdb | mbuffer -s 65536 -m -m 50% -P 80 -o /dev/st0l
>
> Is what I'm seeing pretty much the norm, or is there something I can do to 
> get better throughput?
>
> Thanks in advance for any assistance you can provide.
> Dave
>
>
>
Have you set the Write Immediate Filemark option for the st driver? 

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: LTO-4 iSCSI performance less than expected ...

[The Lee-Man]

On Friday, April 14, 2017 at 4:31:05 AM UTC-7, 
david.partri...@perdrix.co.uk wrote:
>
> Let's try another tack.
>
> Will "mt-st -f /dev/st0l /stoptions 35" turn on MTWEOFI?
>
> Dave
>

Hi Dave:

I don't know. I download mt-st, which I've never seen before, and perhaps 
you mean:

> # mt-st -f  setstoptions 

But the flag value is not "35". I believe you would want the value of 
MT_ST_NOWAIT_EOF,
which is 0x8000. If I had a tape drive and more time I'd test it, but I do 
not.

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Moving target-isns to the open-iscsi github project

[The Lee-Man]

I would like to move the target-isns project, owned and managed by 
Christophe Vu-Brugier on github, under our open-iscsi project.

Chris and Andy in particular, do you have any objections?

See https://github.com/cvubrugier/target-isns for the target-isns project.

-- 
Lee Duncan

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: LTO-4 iSCSI performance less than expected ...

[The Lee-Man]

On Friday, March 31, 2017 at 2:23:30 PM UTC-7, 
david.partri...@perdrix.co.uk wrote:
>
> I don't know?  How do I find out?  Should I have it set?
>
>>
>> Have you set the Write Immediate Filemark option for the st driver? 
>>
>

There are a couple of ways to enable writing immediate filemarks in the st 
driver. One is to use the MTWEOFI ioctl(). If you have access to the source 
code for your application, this is a good way to go.

But I added a user-settable option with kernel commit  
c743e44fbb1f8668941e83de07662b1ecd33d083. It allows you to tell the st 
driver to write immediate file marks by setting a sysfs attribute.

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: installing initiator and target

[The Lee-Man]

On Sunday, July 30, 2017 at 10:01:20 PM UTC-7, jayshankar nair wrote:
>
> Hi,
>  I like to install the iscsi initiator and target on fedora 25. PLease 
> email me the README file.
>
> Thanks,
> Jayshankar
>

Why do you not install the package and look at the README?

Or use git to download the sources, and look at the README.

This is not a file to email service. 

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Recovering initiator connection when target (IET) is restarted - root over iscsi

[The Lee-Man]

On Monday, August 7, 2017 at 2:35:26 PM UTC-7, Bob Marris wrote:
>
> I'm running my initiator's root partition via open-iscsi to an IET target.
>
> I'm testing failure scenarios, and in the event of a target reboot (or 
> daemon restart) my initiator seems to hang.  I was hoping it would be able 
> to recover and just carry on running once the target came back. Since this 
> is my root partition I can't see any logs once it hangs
>
> I've increased node.session.timeo.replacement_timeout.  
>
> I've also added "discovery.sendtargets.use_discoveryd = Yes"  in  
> /etc/iscsi/send_targets/192.168.1.5,3260/st_config, thinking that it 
> would allow the initiator to rediscover/login to the target when it comes 
> back up.
>
> I do not believe having your target rediscovered is the right approach and 
is likely just mucking things up. I suggest you reset this back to default, 
until you figure out the issue.
 

> Is it my initiator configuration or somehow a failing of IET at the target 
> side?
>
>
> My settings at the initiator end are:
>
> pi@homeauto:/etc/iscsi $ sudo iscsiadm -m node -T 
> iqn.2017-07.eu.bobta:domoticz -p 192.168.1.5
> # BEGIN RECORD 2.0-873
> node.name = iqn.2017-07.eu.bobta:domoticz
> node.tpgt = 1
> node.startup = automatic
> node.leading_login = No
> iface.hwaddress = 
> iface.ipaddress = 
> iface.iscsi_ifacename = default
> iface.net_ifacename = 
> iface.transport_name = tcp
> iface.initiatorname = 
> iface.bootproto = 
> iface.subnet_mask = 
> iface.gateway = 
> iface.ipv6_autocfg = 
> iface.linklocal_autocfg = 
> iface.router_autocfg = 
> iface.ipv6_linklocal = 
> iface.ipv6_router = 
> iface.state = 
> iface.vlan_id = 0
> iface.vlan_priority = 0
> iface.vlan_state = 
> iface.iface_num = 0
> iface.mtu = 0
> iface.port = 0
> node.discovery_address = 192.168.1.5
> node.discovery_port = 3260
> node.discovery_type = send_targets
> node.session.initial_cmdsn = 0
> node.session.initial_login_retry_max = 8
> node.session.xmit_thread_priority = -20
> node.session.cmds_max = 128
> node.session.queue_depth = 32
> node.session.nr_sessions = 1
> node.session.auth.authmethod = CHAP
> node.session.auth.username = bob
> node.session.auth.password = 
> node.session.auth.username_in = 
> node.session.auth.password_in = 
> node.session.timeo.replacement_timeout = 1200
> node.session.err_timeo.abort_timeout = 15
> node.session.err_timeo.lu_reset_timeout = 30
> node.session.err_timeo.tgt_reset_timeout = 30
> node.session.err_timeo.host_reset_timeout = 60
> node.session.iscsi.FastAbort = Yes
> node.session.iscsi.InitialR2T = No
> node.session.iscsi.ImmediateData = Yes
> node.session.iscsi.FirstBurstLength = 262144
> node.session.iscsi.MaxBurstLength = 16776192
> node.session.iscsi.DefaultTime2Retain = 0
> node.session.iscsi.DefaultTime2Wait = 2
> node.session.iscsi.MaxConnections = 1
> node.session.iscsi.MaxOutstandingR2T = 1
> node.session.iscsi.ERL = 0
> node.conn[0].address = 192.168.1.5
> node.conn[0].port = 3260
> node.conn[0].startup = automatic
> node.conn[0].tcp.window_size = 524288
> node.conn[0].tcp.type_of_service = 0
> node.conn[0].timeo.logout_timeout = 15
> node.conn[0].timeo.login_timeout = 15
> node.conn[0].timeo.auth_timeout = 45
> node.conn[0].timeo.noop_out_interval = 0
> node.conn[0].timeo.noop_out_timeout = 0
> node.conn[0].iscsi.MaxXmitDataSegmentLength = 0
> node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
> node.conn[0].iscsi.HeaderDigest = None
> node.conn[0].iscsi.DataDigest = None
> node.conn[0].iscsi.IFMarker = No
> node.conn[0].iscsi.OFMarker = No
> # END RECORD
>
> Any help would be very much appreciated!
>

It looks like you are using CHAP? That shouldn't be an issue, but to 
simplify things you might want to remove that.

I tested using iet as a target on SLE 12 SP1 and open-iscsi initiator on 
SLE 12 SP2. I ran a "dd" to read all the blocks on the iscsi target from 
the inititator, as well as running a "mkfs.ext3". Then I restarted the iet 
daemon. Both IO streams paused then continued. In other words, I cannot 
reproduce your issue.

Can you do some testing? When the system hangs, is it the initiator or the 
target? You should be able to log into the target from another (different) 
initiator to see if the target's still working.

You can also enable debugging on the target and the initiator to see what's 
happening when your hang occurs.

I would suggest testing by using your iscsi target as a *non-root* disc. If 
it's your root disc and you have issues, you can't debug them very easily 
if you're using it as your root disc.
-- 
Lee Duncan 

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: How to limit logins to discovered iscsi-targets on Linux

[The Lee-Man]

On Tuesday, July 18, 2017 at 7:43:13 AM UTC-7, Damir wrote:
>
> Hello!
>
> I try to configure iscsi initiator on Linux (Mageia 5 x86_64, open-iscsi). 
> The goal is to automatically connect to iscsi-storage by starting linux. 
> Iscsi-storae is configured on 10.11.104.10 (by the provider, and I don't 
> have any access to the storage management) 
>
> 1) I discovered targets with command:
>

Discoverd is a thread that gets started that repeated does your discovery 
command.
 

> [root@localhost ~]# iscsiadm -m discovery -p 10.11.104.10 -t st
> And get a list of avalaible targets:10.11.104.10:3260,1 
> iqn.1991-05.com.microsoft:bckp-104-target10.10.83.10:3260,1 
> iqn.1991-05.com.microsoft:bckp-104-target10.11.100.10:3260,1 
> iqn.1991-05.com.microsoft:bckp-104-target10.11.106.10:3260,1 
> iqn.1991-05.com.microsoft:bckp-104-target10.11.114.10:3260,1 
> iqn.1991-05.com.microsoft:bckp-104-target
>
>
So you've found 5 paths to the same target. 

>  2) To initiate the connection on startup I changed the value of 
> discovery.sendtargets.use_discoveryd = No to Yes
>
> /var/lib/iscsi/send_targets/10.11.104.10,3260/st_config:
>
> # BEGIN RECORD 2.0-872
> discovery.startup = manual
> discovery.type = sendtargets
> discovery.sendtargets.address = 10.11.104.10
> discovery.sendtargets.port = 3260
> discovery.sendtargets.auth.authmethod = None
> discovery.sendtargets.timeo.login_timeout = 15
> discovery.sendtargets.use_discoveryd = Yes
> discovery.sendtargets.discoveryd_poll_inval = 30
> discovery.sendtargets.reopen_max = 5
> discovery.sendtargets.timeo.auth_timeout = 45
> discovery.sendtargets.timeo.active_timeout = 30
> discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768
> # END RECORD
>
> In /etc/iscsi/iscsid.conf:
>
> node.startup = manual
> node.leading_login = No
>
>
As iscsid.conf explains, leading_login only applies when "startup" is set 
to "automatic".

>  After restarting of iscsid I get /dev/sdb disk and can work with it. But 
> see also in /var/log/messages the foolowing:
>
> iscsid: Logging in to [iface: default, target: 
> iqn.1991-05.com.microsoft:bckp-104-target, portal: 10.10.83.10,3260] 
> (multiple)
> iscsid: Logging in to [iface: default, target: 
> iqn.1991-05.com.microsoft:bckp-104-target, portal: 10.11.100.10,3260] 
> (multiple)
> iscsid: Logging in to [iface: default, target: 
> iqn.1991-05.com.microsoft:bckp-104-target, portal: 10.11.106.10,3260] 
> (multiple) 
> iscsid: Logging in to [iface: default, target: 
> iqn.1991-05.com.microsoft:bckp-104-target, portal: 10.11.114.10,3260] 
> (multiple)
>
> It means, that iscsid tries to connect to all discovered targets. I delete 
> unwanted targets with the command: 
>
> iscsiadm -m node -p 10.11.100.10  -T 
> iqn.1991-05.com.microsoft:bckp-104-target -o delete
>
>
 it disappears from /var/lib/iscsi, but all the same in /var/log/messages 
> (there are still connections to all discovered targets). Restarting of 
> iscsid does not change anything.
>
> The question is, how to limit logins to discovered targets to only one 
> target 10.11.104.10:3260,1 iqn.1991-05.com.microsoft:bckp-104-target ?
>

The way to get what you want is to:

1. Set node_startup to automatic in iscisd.conf (and leading_login to Yes)
2. Perform discovery. This should only be needed once. If there are extra 
nodes, i.e. nodes discovered you do not want, delete them (as you noted)
3. run "iscsiadm -m node -l" to login to that one node
4. Reboot to test that the "startup=automatic" works. If not, you may need 
to enable one more systemd service.

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] iscsid: Add qedi ping transport hook

[The Lee-Man]

Applied. Please note that pull requests via github are easier to apply than 
traditional patch emails.

On Wednesday, April 26, 2017 at 2:27:03 AM UTC-7, Nilesh Javali wrote:
>
> iscsiuio ping is operational for qedi. 
> Add missing qedi transport hook for ping support. 
>
> Signed-off-by: Nilesh Javali  
> --- 
>  usr/transport.c | 1 + 
>  1 file changed, 1 insertion(+) 
>
> diff --git a/usr/transport.c b/usr/transport.c 
> index 533ba30..56fab49 100644 
> --- a/usr/transport.c 
> +++ b/usr/transport.c 
> @@ -124,6 +124,7 @@ struct iscsi_transport_template qedi = { 
>  .ep_poll= ktransport_ep_poll, 
>  .ep_disconnect= ktransport_ep_disconnect, 
>  .set_net_config = uip_broadcast_params, 
> +.exec_ping  = uip_broadcast_ping_req, 
>  }; 
>   
>  static struct iscsi_transport_template *iscsi_transport_templates[] = { 
> -- 
> 1.8.3.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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] C/Python initiator userspace API approach.

[The Lee-Man]

On Wednesday, April 26, 2017 at 9:15:50 AM UTC-7, Christian Seiler wrote:
>
> On 04/26/2017 01:03 PM, Gris Ge wrote: 
> > On Wed, Apr 26, 2017 at 09:14:35AM +0200, Christian Seiler wrote: 
> >> On 04/26/2017 01:11 AM, Gris Ge wrote: 
> >>> B) Expand iscsid to listen on a socket for IPC with JSON output. 
> >>> Pro: 
> >>> * Easy to create language bindings via JSON + IPC. 
> >>> Con: 
> >>> * More code work on iscsid like lock, ipc listener, json 
> >>>   formatter and etc. 
> >> 
> >> I don't think creating yet another own IPC interface is a good 
> >> idea, there are already way too many IPC protocols in the Linux 
> >> plubming space. I believe that DBus would be the obvious choice 
> >> here. This has several advantages: 
> > Given my bad grudges of dbus, I am afraid I could not able to provide 
> > demo/POC of dbus interface/service of open-iscsi. 
>
> Well, if it's under serious consideration, I'd be willing to put 
> my money^Wtime where my mouth is and write some code for this. 
> But only if there's a decent chance that this will not be for 
> nothing. If either Lee or Chris say "we'll never merge DBus 
> support" I'm not really that interested in working on that, for 
> obvious reasons. ;-) 
>
> Regards, 
> Christian 
>

Christian:

I am seriously interested in both adding an API like this (if done right) 
and in adding more/better locking so that iscsid could support more 
parallelism.

But I know almost nothing about DBus. Why would anyone say no to dbus? I 
know that at SUSE we require a security analysis before we allow a new 
daemon that uses DBus, but I assume that just meant it had lots of power 
(which could be used for evil but usually isn't). Can you explain the DBus 
trade-off to me?

-- 
Lee

-- 
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 https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.