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 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 a topic in the 
>> Google Groups "open-iscsi" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/open-iscsi/RyQZI1DsDw8/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.

Reply via email to