Antw: [EXT] Re: [PATCH 0/2] scsi:donot skip lun if inquiry returns PQ=1 for all hosts

[Ulrich Windl]

>>> Christoph Hellwig  schrieb am 15.12.2022 um 08:06 in
Nachricht :
> On Wed, Dec 14, 2022 at 03:08:44PM +0800, Wenchao Hao wrote:
>> When iSCSI initiator logged in target, the target attached none valid
>> lun but lun0. lun0 is not an valid disk, while it would response
>> inquiry command with PQ=1 and other general scsi commands like probe lun.
>> The others luns of target is added/removed dynamicly.
> 
> I can't find any special casing of LUN0 in RFC7144, can you clarify
> where you think that treats LUN0 any differently than other transports?

Actusally I have no idea, but as a user of FC SAN systems I can remember a case 
when a storage system had to present a dummy LUN0 to enable hosts to find other 
LUNs (while LUN0 was never actually used). Maybe the client code was imperfect, 
I don't 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/Y5rHX95Vvl1aLhbp%40infradead.org 
> .




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/639AD5C002A100050749%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH 1/2] scsi:core:Add sysfs interface to control if skip lun with PQ=1

[Ulrich Windl]

>>> "'Wenchao Hao' via open-iscsi"  schrieb am
14.12.2022 um 08:08 in Nachricht
<20221214070846.1808300-2-haowenc...@huawei.com>:

...

> +  * Targets set PQ=1 would be skipped if shost->no_skip_pq1 is not set

I would write "Targets that set ..." instead.

...


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/63997BC402A1000506F5%40gwsmtp.uni-regensburg.de.

Antw: Re: [EXT] Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

[Ulrich Windl]

>>> Ulrich Windl schrieb am 25.11.2022 um 08:11 in Nachricht <63806AA5.95B : 
>>> 161 :
60728>:
>>>> "'Wenchao Hao' via open-iscsi"  schrieb am
> 24.11.2022 um 16:30 in Nachricht
> <2d0439ba-7fb7-47ef-b52c-a866dc0c86...@googlegroups.com>:
> > On Thursday, November 24, 2022 at 6:06:09 PM UTC+8 Uli wrote:
> > 
> >> >>> "'Lee Duncan' via open-iscsi"  schrieb am 
> >> 23.11.2022 um 17:47 in Nachricht 
> >> <0f7258d5-ff8e-fa4e...@suse.com>: 
> >> > On 11/22/22 20:41, Wenchao Hao wrote: 
> >>
> >> ... 
> >> > Again, I don't believe that's correct. I will test it. 
> >> ... 
> >> Maybe a session capture (via serial line or so) to show real facts would 
> >> be helpful for the discussion.
> > 
> > 
> > Sorry, I can not understand this, could you describe more detail?
> 

Sorry, I swapped the roles of Wenchao Hao and Lee Duncan. Completely my fault...

> Wenchao Hao claimed something would not work correctly, and you doubted it.
> So it would have bean easiest to demonstrate the issue (by Wenchao Hao) by 
> some session capture starting from kernel boot.
> That's what I trued to say. Probably easier than believing or not.
> 
> Regards,
> Ulrich
> 
> >  
> > 
> >>
> >> Personally I think that information the kernel needs to continue working 
> >> (e.g. the mount table) should be in the kernel. 
> >> Maybe user-land tools can manage the info there (in the kernel, via API), 
> >> but the primary source should be the kernel. 
> >>
> >> 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/open-iscsi/2d0439ba-7fb7-47ef-b52c-a866dc0
> >  
> c 
> > 86e1n%40googlegroups.com.
> 
> 
> 
> 




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/63806AFB02A10004FFCA%40gwsmtp.uni-regensburg.de.

Antw: Re: [EXT] Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

[Ulrich Windl]

>>> "'Wenchao Hao' via open-iscsi"  schrieb am
24.11.2022 um 16:30 in Nachricht
<2d0439ba-7fb7-47ef-b52c-a866dc0c86...@googlegroups.com>:
> On Thursday, November 24, 2022 at 6:06:09 PM UTC+8 Uli wrote:
> 
>> >>> "'Lee Duncan' via open-iscsi"  schrieb am 
>> 23.11.2022 um 17:47 in Nachricht 
>> <0f7258d5-ff8e-fa4e...@suse.com>: 
>> > On 11/22/22 20:41, Wenchao Hao wrote: 
>>
>> ... 
>> > Again, I don't believe that's correct. I will test it. 
>> ... 
>> Maybe a session capture (via serial line or so) to show real facts would 
>> be helpful for the discussion.
> 
> 
> Sorry, I can not understand this, could you describe more detail?

Wenchao Hao claimed something would not work correctly, and you doubted it.
So it would have bean easiest to demonstrate the issue (by Wenchao Hao) by some 
session capture starting from kernel boot.
That's what I trued to say. Probably easier than believing or not.

Regards,
Ulrich

>  
> 
>>
>> Personally I think that information the kernel needs to continue working 
>> (e.g. the mount table) should be in the kernel. 
>> Maybe user-land tools can manage the info there (in the kernel, via API), 
>> but the primary source should be the kernel. 
>>
>> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/2d0439ba-7fb7-47ef-b52c-a866dc0c 
> 86e1n%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/63806AA502A10004FFC6%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

[Ulrich Windl]

>>> "'Lee Duncan' via open-iscsi"  schrieb am
23.11.2022 um 17:47 in Nachricht
<0f7258d5-ff8e-fa4e-ab8e-5125c42a6...@suse.com>:
> On 11/22/22 20:41, Wenchao Hao wrote:

...
> Again, I don't believe that's correct. I will test it.
...
Maybe a session capture (via serial line or so) to show real facts would be 
helpful for the discussion.
Personally I think that information the kernel needs to continue working (e.g. 
the mount table) should be in the kernel.
Maybe user-land tools can manage the info there (in the kernel, via API), but 
the primary source should be the kernel.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/637F420902A10004FF7D%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: [PATCH v6] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

[Ulrich Windl]

>>> "'Wenchao Hao' via open-iscsi"  schrieb am
21.11.2022 um 15:17 in Nachricht
<89692b2b-90f7-e8e8-fa77-f14dbe996...@huawei.com>:
> On 2022/11/9 11:47, Mike Christie wrote:
>> On 11/7/22 7:44 PM, Wenchao Hao wrote:
>>> I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION
>>> for multiple times which should be fixed.
>>>  
>>> +static char *iscsi_session_target_state_names[] = {
>>> +   "UNBOUND",
>>> +   "ALLOCATED",
>>> +   "SCANNED",
>>> +   "UNBINDING",
>>> +};
>> 
>> I think maybe Lee meant you to do something like:
>> 
>> static int iscsi_target_state_to_name[] = {
>>  [ISCSI_SESSION_TARGET_UNBOUND] = "UNBOUND",
>>  [ISCSI_SESSION_TARGET_ALLOCATED] = "ALLOCATED",
>>  .
>> 
>> 
> 
> Define array as following and remove previous helper function:
> 
> static char *iscsi_session_target_state_name[] = {
>[ISCSI_SESSION_TARGET_UNBOUND]   = "UNBOUND",
>[ISCSI_SESSION_TARGET_ALLOCATED] = "ALLOCATED",
>[ISCSI_SESSION_TARGET_SCANNED]   = "SCANNED",
>[ISCSI_SESSION_TARGET_UNBINDING] = "UNBINDING",
> };
> 
> Reference the array directly:

Actually I think with a modern optimizing compiler there should be little 
difference in the code created.

> 
> static ssize_t
> show_priv_session_target_state(struct device *dev, struct device_attribute 
> *attr,
>char *buf)
> {
>struct iscsi_cls_session *session = iscsi_dev_to_session(dev->parent);
>return sysfs_emit(buf, "%s\n",
>
> iscsi_session_target_state_name[session->target_state]);
> }
> 
>>> +   spin_lock_irqsave(>lock, flags);
>>> +   if (session->target_state == ISCSI_SESSION_TARGET_ALLOCATED) {
>>> +   spin_unlock_irqrestore(>lock, flags);
>>> +   if (session->ida_used)
>>> +   ida_free(_sess_ida, session->target_id);
>>> +   ISCSI_DBG_TRANS_SESSION(session, "Donot unbind sesison: 
>>> allocated\n");
>> 
>> Could you change the error message to "Skipping target unbinding: Session 
> not yet scanned.\n"
>> 
>>> +   goto unbind_session_exit;
>>> +   }
>> 
>> Just add a newline/return here.
> 
> Actually we should skip unbind this session if call into 
> __iscsi_unbind_session() with target state
> is ALLOCATED. So I removed the check, and check only one condition in 
> __iscsi_unbind_session(): if the
> target state is SCANNED.
> 
>> 
>> I think you want to move both state checks to after the we take the host 
> lock and
>> session lock after the line above. You don't have to take the lock multiple 
> times
>> and we can drop the target_id == ISCSI_MAX_TARGET since it would then rely 
> on the
>> state checks (I left out the ISCSI_DBG_TRANS_SESSION because I'm lazy):
>> 
>>  bool remove_target = false;
>> .
>> 
>> 
> I think it's not necessary to add a flag remove_target, here is my changes 
> for function __iscsi_unbind_session:
> 
> @@ -1966,23 +1977,28 @@ static void __iscsi_unbind_session(struct 
> work_struct *work)
> /* Prevent new scans and make sure scanning is not in progress */
> mutex_lock(>mutex);
> spin_lock_irqsave(>lock, flags);
> -   if (session->target_id == ISCSI_MAX_TARGET) {
> +   if (session->target_state != ISCSI_SESSION_TARGET_SCANNED) {
> spin_unlock_irqrestore(>lock, flags);
> mutex_unlock(>mutex);
> -   goto unbind_session_exit;
> +   ISCSI_DBG_TRANS_SESSION(session, "Skipping target unbinding: 
> Session is %s.\n",
> +   
> iscsi_session_target_state_name[session->target_state]);
> +   return;
> }
> -
> target_id = session->target_id;
> session->target_id = ISCSI_MAX_TARGET;
> +   session->target_state = ISCSI_SESSION_TARGET_UNBINDING;
> spin_unlock_irqrestore(>lock, flags);
> mutex_unlock(>mutex);
>  
> scsi_remove_target(>dev);
>  
> +   spin_lock_irqsave(>lock, flags);
> +   session->target_state = ISCSI_SESSION_TARGET_UNBOUND;
> +   spin_unlock_irqrestore(>lock, flags);
> +
> if (session->ida_used)
> ida_free(_sess_ida, target_id);
>  
> -unbind_session_exit:
> iscsi_session_event(session, ISCSI_KEVENT_UNBIND_SESSION);
> ISCSI_DBG_TRANS_SESSION(session, "Completed target removal\n");
>  }
> 
> And the function looks like following after change:
> 
> 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 */
>   

Antw: [EXT] Re: [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd

[Ulrich Windl]

>>> Adam Hutchinson  schrieb am 15.06.2022 um 20:57 in
Nachricht
:
> Is there any reason not to use time as an indicator that pending R2Ts
> need to be processed?  Could R2Ts be tagged with a timestamp when
> received and only given priority over new commands if the age of the
> R2T at the head exceeds some configurable limit? This would guarantee
> R2T will eventually be serviced even if the block layer doesn't reduce
> the submission rate of new commands, it wouldn't remove the
> performance benefits of the current algorithm which gives priority to
> new commands and it would be a relatively simple solution.  A
> threshold of 0 could indicate that R2Ts should always be given
> priority over new commands. Just a thought..

I had similar thought comparing SCSI command scheduling with process scheduling
real-time scheduling can cause starvation when newer requests are postponed 
indefinitely,
while the classic scheduler increases the chance of longer-waiting tasks to be 
scheduled next.
In any case that would require some sorting of the queue (or searching for a 
maximum/minimum in the requests which is equivalent).

Regards,
Ulrich


> 
> Regards,
> Adam
> 
> On Wed, Jun 15, 2022 at 11:37 AM Mike Christie
>  wrote:
>>
>> On 6/7/22 8:19 AM, Dmitry Bogdanov wrote:
>> > In function iscsi_data_xmit (TX worker) there is walking through the
>> > queue of new SCSI commands that is replenished in parallell. And only
>> > after that queue got emptied the function will start sending pending
>> > DataOut PDUs. That lead to DataOut timer time out on target side and
>> > to connection reinstatment.
>> >
>> > This patch swaps walking through the new commands queue and the pending
>> > DataOut queue. To make a preference to ongoing commands over new ones.
>> >
>> > Reviewed-by: Konstantin Shelekhin 
>> > Signed-off-by: Dmitry Bogdanov 
>>
>> Let's do this patch. I've tried so many combos of implementations and
>> they all have different perf gains or losses with different workloads.
>> I've already been going back and forth with myself for over a year
>> (the link for my patch in the other mail was version N) and I don't
>> think a common solution is going to happen.
>>
>> You patch fixes the bug, and I've found a workaround for my issue
>> where I tweak the queue depth, so I think we will be ok.
>>
>> Reviewed-by: Mike Christie 
>>
>> --
>> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/237bed01-819a-55be-5163-274fac3b 
> 61e6%40oracle.com.
> 
> 
> 
> -- 
> "Things turn out best for the people who make the best out of the way
> things turn out." - Art Linkletter
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/CAFU8FUgwMX_d85OG%2BqC%2BqTX-NpF 
> iSVkwBtradzAmeJW-3PCmEQ%40mail.gmail.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/62AC170C02A10004B106%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd

[Ulrich Windl]

Hi!

In my primitive point of view iSCSI is just "another type of cable", making me 
wonder:
Is iSCSI allowed to reorder the requests at all? Shouldn't the block layer or 
initiator do so, or the target doing out-of order processing (tagged queueing)?

I mean: If there is a problem that occurs even without using iSCSI, should 
iSCSI try to fix it?

Regards,
Ulrich

>>> Mike Christie  schrieb am 09.06.2022 um 22:58 
>>> in
Nachricht :
> On 6/9/22 4:02 AM, Dmitriy Bogdanov wrote:
>> Hi Mike,
>> 
 On 6/8/22 9:16 AM, Dmitriy Bogdanov wrote:
> On 6/7/22 10:55 AM, Mike Christie wrote:
>> On 6/7/22 8:19 AM, Dmitry Bogdanov wrote:
>>> In function iscsi_data_xmit (TX worker) there is walking through the
>>> queue of new SCSI commands that is replenished in parallell. And only
>>> after that queue got emptied the function will start sending pending
>>> DataOut PDUs. That lead to DataOut timer time out on target side and
>>> to connection reinstatment.
>>>
>>> This patch swaps walking through the new commands queue and the pending
>>> DataOut queue. To make a preference to ongoing commands over new ones.
>>>
>>
>> ...
>>
>>>  task = list_entry(conn->cmdqueue.next, struct iscsi_task,
>>> @@ -1594,28 +1616,10 @@ static int iscsi_data_xmit(struct iscsi_conn 
>>> *conn)
>>>   */
>>>  if (!list_empty(>mgmtqueue))
>>>  goto check_mgmt;
>>> +if (!list_empty(>requeue))
>>> +goto check_requeue;
>>
>>
>>
>> Hey, I've been posting a similar patch:
>>
>> 
> https://urldefense.com/v3/__https://www.spinics.net/lists/linux-scsi/msg15693 
> 9.html__;!!ACWV5N9M2RV99hQ!LHLghPLuyBZadpsGme03-HBoowa8sNiZYMKxKoz5E_BNu-M9-B
> iuNV_JS9kFxhnumNfhrxuR7qVdIaOH5X7iTfMO$
>>
>> A problem I hit is a possible pref regression so I tried to allow
>> us to start up a burst of cmds in parallel. It's pretty simple where
>> we allow up to a queue's worth of cmds to start. It doesn't try to
>> check that all cmds are from the same queue or anything fancy to try
>> and keep the code simple. Mostly just assuming users might try to bunch
>> cmds together during submission or they might hit the queue plugging
>> code.
>>
>> What do you think?
>
> Oh yeah, what about a modparam batch_limit? It's between 0 and 
> cmd_per_lun.
> 0 would check after every transmission like above.

  Did you really face with a perf regression? I could not imagine how it is
 possible.
 DataOut PDU contains a data too, so a throughput performance cannot be
 decreased by sending DataOut PDUs.
>>>
>>>
>>> We can agree that queue plugging and batching improves throughput right?
>>> The app or block layer may try to batch commands. It could be with something
>>> like fio's batch args or you hit the block layer queue plugging.
>> 
>> I agree that those features 100% gives an improvement of a throughput on 
> local
>> devices on serial interfaces like SATA1. Since SATA2 (Native Command 
> Queuing)
>> devices can reorder incoming commmands to provide the best thoughput.
>> SCSI I guess has similar feature from the very beginning.
>> But on remote devices (iSCSI and FC) it is not 100% - initiators's command
>> order may be reordered by the network protocol nature itself. I mean 1PDU vs
>> R2T+DataOut PDUs, PDU resending due to crc errors or something like that.
> I think we are talking about slightly different things. You are coming up 
> with
> different possible scenarios where it doesn't work. I get them. You are 
> correct
> for those cases. I'm not talking about those cases. I'm talking about the 
> specific
> case I described.
> 
> I'm saying we have targets where we use backends that get improved 
> performance
> when they get batched cmds. When the network is ok, and the user's app is
> batching cmds, they come from the app down to the target's backend device as
> a batch. My concern is that with your patch we will no longer get that 
> behavior.
> 
> The reason is that the target and initiator can do:
> 
> 1. initiator sends scsi cmd pdu1
> 2. target sends R2T
> 3. initiator sees R2T and hits the goto. Sends data
> 4. target reads in data. Sends cmd to block layer.
> 5. initiator sends scsi cmd pdu2
> 6. target sends R2T
> 7. initiator reads in R2T sends data.
> 8. target reads in data and sends cmd to block layer.
> 
> The problem here could be between 4 and 8 the block layer has run the queue
> and sent that one cmd to the real device already because we have that extra
> delay now. So when I implemented the fix in the same way as you and I run
> iostat I would see lower aqu-sz for example.
> 
> With the current code we might not have that extra delay between 4 - 8 so
> I would see:
> 
> 1. initiator sends scsi cmd pdu1
> 2. initiator sends scsi cmd pdu2
> 3. initiator sends scsi cmd pdu3
> 4. target 

Antw: [EXT] Re: [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd

[Ulrich Windl]

>>> Mike Christie  schrieb am 08.06.2022 um 17:36 
>>> in
Nachricht <48af6f5f-c3b6-ac65-836d-518153ab2...@oracle.com>:
> On 6/8/22 9:16 AM, Dmitriy Bogdanov wrote:
>> Hi Mike,
>> 
>>> On 6/7/22 10:55 AM, Mike Christie wrote:
 On 6/7/22 8:19 AM, Dmitry Bogdanov wrote:
> In function iscsi_data_xmit (TX worker) there is walking through the
> queue of new SCSI commands that is replenished in parallell. And only
> after that queue got emptied the function will start sending pending
> DataOut PDUs. That lead to DataOut timer time out on target side and
> to connection reinstatment.
>
> This patch swaps walking through the new commands queue and the pending
> DataOut queue. To make a preference to ongoing commands over new ones.
>

 ...

>  task = list_entry(conn->cmdqueue.next, struct iscsi_task,
> @@ -1594,28 +1616,10 @@ static int iscsi_data_xmit(struct iscsi_conn 
> *conn)
>   */
>  if (!list_empty(>mgmtqueue))
>  goto check_mgmt;
> +if (!list_empty(>requeue))
> +goto check_requeue;



 Hey, I've been posting a similar patch:

 
> https://urldefense.com/v3/__https://www.spinics.net/lists/linux-scsi/msg15693 
> 9.html__;!!ACWV5N9M2RV99hQ!LHLghPLuyBZadpsGme03-HBoowa8sNiZYMKxKoz5E_BNu-M9-B
> iuNV_JS9kFxhnumNfhrxuR7qVdIaOH5X7iTfMO$ 

 A problem I hit is a possible pref regression so I tried to allow
 us to start up a burst of cmds in parallel. It's pretty simple where
 we allow up to a queue's worth of cmds to start. It doesn't try to
 check that all cmds are from the same queue or anything fancy to try
 and keep the code simple. Mostly just assuming users might try to bunch
 cmds together during submission or they might hit the queue plugging
 code.

 What do you think?
>>>
>>> Oh yeah, what about a modparam batch_limit? It's between 0 and cmd_per_lun.
>>> 0 would check after every transmission like above.
>> 
>>  Did you really face with a perf regression? I could not imagine how it is
>> possible.
>> DataOut PDU contains a data too, so a throughput performance cannot be
>> decreased by sending DataOut PDUs.
> 
> 
> We can agree that queue plugging and batching improves throughput right?

Hi!

Isn't that the classic "throughput vs. response time"? I think you cannot 
optimize one without affecting the other.
(I can remember discussions like "You are sending one ethernet packet for each 
key pressed; are you crazy?" when network admins felt worried about throughput)

> The app or block layer may try to batch commands. It could be with something
> like fio's batch args or you hit the block layer queue plugging.
> 
> With the current code we can end up sending all cmds to the target in a way
> the target can send them to the real device batched. For example, we send 
> off
> the initial N scsi command PDUs in one run of iscsi_data_xmit. The target 
> reads
> them in, and sends off N R2Ts. We are able to read N R2Ts in the same call.
> And again we are able to send the needed data for them in one call of
> iscsi_data_xmit. The target is able to read in the data and send off the
> WRITEs to the physical device in a batch.
> 
> With your patch, we can end up not batching them like the app/block layer
> intended. For example, we now call iscsi_data_xmit and in the cmdqueue loop.
> We've sent N - M scsi cmd PDUs, then see that we've got an incoming R2T to
> handle. So we goto check_requeue. We send the needed data. The target then
> starts to send the cmd to the physical device. If we have read in multiple
> R2Ts then we will continue the requeue loop. And so we might be able to send
> the data fast enough that the target can then send those commands to the
> physical device. But we've now broken up the batching the upper layers sent
> to us and we were doing before.
> 
>> 
>>  The only thing is a latency performance. But that is not an easy question.
> 
> Agree latency is important and that's why I was saying we can make it config
> option. Users can continue to try and batch their cmds and we don't break
> them. We also fix the bug in that we don't get stuck in the cmdqueue loop
> always taking in new cmds.
> 
>> IMHO, a system should strive to reduce a maximum value of the latency almost
>> without impacting of a minimum value (prefer current commands) instead of
>> to reduce a minimum value of the latency to the detriment of maximum value
>> (prefer new commands).
>> 
>>  Any preference of new commands over current ones looks like an io scheduler
> 
> I can see your point of view where you see it as preferring new cmds
> vs existing. It's probably due to my patch not hooking into commit_rqs
> and trying to figure out the batching exactly. It's more of a simple
> estimate.

Is it also about the classic "reads stall when all buffers are dirty" (reads to 
a fast device may time-out 

Antw: [EXT] [PATCH] scsi: iscsi: fix harmless double shift bug

[Ulrich Windl]

>>> Dan Carpenter  schrieb am 21.04.2022 um 17:03 in
Nachricht :
> These flags are supposed to be bit numbers.  Right now they cause a
> double shift bug where we use BIT(BIT(2)) instead of BIT(2).
> Fortunately, the bit numbers are small and it's done consistently so it
> does not cause an issue at run time.
> 
> Fixes: 5bd856256f8c ("scsi: iscsi: Merge suspend fields")
> Signed-off-by: Dan Carpenter 
> ---
>  include/scsi/libiscsi.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
> index d0a24779c52d..c0703cd20a99 100644
> --- a/include/scsi/libiscsi.h
> +++ b/include/scsi/libiscsi.h
> @@ -54,9 +54,9 @@ enum {
>  #define ISID_SIZE6
>  
>  /* Connection flags */
> -#define ISCSI_CONN_FLAG_SUSPEND_TX   BIT(0)
> -#define ISCSI_CONN_FLAG_SUSPEND_RX   BIT(1)
> -#define ISCSI_CONN_FLAG_BOUNDBIT(2)
> +#define ISCSI_CONN_FLAG_SUSPEND_TX   0
> +#define ISCSI_CONN_FLAG_SUSPEND_RX   1
> +#define ISCSI_CONN_FLAG_BOUND2

Actually it's not the "flag" then, but the "flag's bit position".
Personally I think applying BIT() again is the bug, not the definition.

>  
>  #define ISCSI_ITT_MASK   0x1fff
>  #define ISCSI_TOTAL_CMDS_MAX 4096
> -- 
> 2.20.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/YmFyWHf8nrrx%2BSHa%40kili.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6262654D02A100049812%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: [PATCH v2] scsi: iscsi: Fix multiple iscsi session unbind event sent to userspace

[Ulrich Windl]

>>> Mike Christie  schrieb am 20.04.2022 um 18:28 
>>> in
Nachricht <938bca13-2dcc-24c0-51b5-26f7e7238...@oracle.com>:

...
> 
>> diff --git a/include/scsi/scsi_transport_iscsi.h 
> b/include/scsi/scsi_transport_iscsi.h
>> index 9acb8422f680..877632c25e56 100644
>> --- a/include/scsi/scsi_transport_iscsi.h
>> +++ b/include/scsi/scsi_transport_iscsi.h
>> @@ -256,6 +256,7 @@ struct iscsi_cls_session {
>>  struct workqueue_struct *workq;
>>  
>>  unsigned int target_id;
>> +int target_unbound;   /* make sure unbind session only once */
> 
> 
> We don't need the comment since the code using this is so simple
> and the name of the variable tells us what it's for.

Actually I think a comment may be worth it, but it should say what the variable 
expresses, not what it is used for
(the use may change, but hopefully not the semantics (unless updated globally)).
So maybe: /* is target unbound? */
(the question mnark emphasizing that it is a boolean type of variable)
But still, if the name is mostly identical to the comment, one may leave out 
the comment.

Regards,
Ulrich

> 
> 
>>  bool ida_used;
>>  
>>  /*
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/938bca13-2dcc-24c0-51b5-26f7e723 
> 8776%40oracle.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6260F57702A1000497D1%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: Question about iscsi session block

[Ulrich Windl]

>>> Donald Williams  schrieb am 15.02.2022 um 17:25 in
Nachricht
:
> Hello,
>Something else to check is your MPIO configuration.  I have seen this
> same symptom when the linux MPIO feature "queue_if_no_path" was enabled
> 
>  From the /etc/multipath.conf file showing it enabled.
> 
> failbackimmediate
> features"1 queue_if_no_path"

Yes, the actual config is interesting. Especially when usind MD-RAID, you 
typically do not want "1 queue_if_no_path", but if the app can't handle I/O 
errors, one might want it.
For a FC SAN featuring ALUA we use:
...
polling_interval 5
max_polling_interval 20
path_selector "service-time 0"
...
path_checker "tur"
...
fast_io_fail_tmo 5
dev_loss_tmo 600

The logs are helpful, too. For example (there were some paths remaining all the 
time):
Cable was unplugged:
Feb 14 12:56:05 h16 kernel: qla2xxx [:41:00.0]-500b:3: LOOP DOWN detected 
(2 7 0 0).
Feb 14 12:56:10 h16 multipathd[5225]: sdbi: mark as failed
Feb 14 12:56:10 h16 multipathd[5225]: SAP_V11-PM: remaining active paths: 7
Feb 14 12:56:10 h16 kernel: sd 3:0:6:3: rejecting I/O to offline device
Feb 14 12:56:10 h16 kernel: sd 3:0:6:14: rejecting I/O to offline device
Feb 14 12:56:10 h16 kernel: sd 3:0:6:15: rejecting I/O to offline device

So 5 seconds later the paths are offlined.

Cable was re-plugged:
Feb 14 12:56:22 h16 kernel: qla2xxx [:41:00.0]-500a:3: LOOP UP detected (8 
Gbps).
Feb 14 12:56:22 h16 kernel: qla2xxx [:41:00.0]-11a2:3: FEC=enabled (data 
rate).
Feb 14 12:56:26 h16 multipathd[5225]: SAP_CJ1-PM: sdbc - tur checker reports 
path is up
Feb 14 12:56:26 h16 multipathd[5225]: 67:96: reinstated
Feb 14 12:56:26 h16 multipathd[5225]: SAP_CJ1-PM: remaining active paths: 5
Feb 14 12:56:26 h16 kernel: device-mapper: multipath: 254:4: Reinstating path 
67:96.
Feb 14 12:56:26 h16 kernel: device-mapper: multipath: 254:6: Reinstating path 
67:112.

So 4 seconds later new paths are discovered.


Regards,
Ulrich



> 
>  Also, in the past some versions of linux multipathd would wait for a
> very long time before moving all I/O to the remaining path.
> 
>  Regards,
> Don
> 
> 
> On Tue, Feb 15, 2022 at 10:49 AM Zhengyuan Liu 
> wrote:
> 
>> Hi, all
>>
>> We have an online server which uses multipath + iscsi to attach storage
>> from Storage Server. There are two NICs on the server and for each it
>> carries about 20 iscsi sessions and for each session it includes about 50
>>  iscsi devices (yes, there are totally about 2*20*50=2000 iscsi block
>> devices
>>  on the server). The problem is: once a NIC gets faulted, it will take too
>> long
>> (nearly 80s) for multipath to switch to another good NIC link, because it
>> needs to block all iscsi devices over that faulted NIC firstly. The
>> callstack is
>>  shown below:
>>
>> void iscsi_block_session(struct iscsi_cls_session *session)
>> {
>> queue_work(iscsi_eh_timer_workq, >block_work);
>> }
>>
>>  __iscsi_block_session() -> scsi_target_block() -> target_block() ->
>>   device_block() ->  scsi_internal_device_block() -> scsi_stop_queue() ->
>>  blk_mq_quiesce_queue()>synchronize_rcu()
>>
>> For all sessions and all devices, it was processed sequentially, and we
>> have
>> traced that for each synchronize_rcu() call it takes about 80ms, so
>> the total cost
>> is about 80s (80ms * 20 * 50). It's so long that the application can't
>> tolerate and
>> may interrupt service.
>>
>> So my question is that can we optimize the procedure to reduce the time
>> cost on
>> blocking all iscsi devices?  I'm not sure if it is a good idea to increase
>> the
>> workqueue's max_active of iscsi_eh_timer_workq to improve concurrency.
>>
>> Thanks in advance.
>>
>> --
>> 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 view this discussion on the web visit
>> 
> https://groups.google.com/d/msgid/open-iscsi/CAOOPZo4uNCicVmoHa2za0%3DO1_XiBd 
> tBvTuUzqBTeBc3FmDqEJw%40mail.gmail.com
>> .
>>
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/CAK3e-EZbJMDHkozGiz8LnMNAZ%2BSoC 
> A%2BQeK0kpkqM4vQ4pz86SQ%40mail.gmail.com.



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/620CCE2002A100047D30%40gwsmtp.uni-regensburg.de.

Antw: [EXT] hostbyte=DID_TRANSPORT_DISRUPTED: network issues or?

[Ulrich Windl]

  >>> Mauricio  schrieb am 26.11.2021 um 15:52 in 
Nachricht
<0c84ea13-e5f5-4755-8f34-3b81dd0040...@googlegroups.com>:
> Now I was able to address my issue with the testbox, I can mount the 
> LUN in that host without issues. So it is time to switch back to the 
> problem box, which started having issues since the last reboot. I apply the 
> solution used in the testbox and then restart the service:
> 
> [root@problembox ~]# systemctl restart iscsi
> [root@problembox ~]#
> 
> And it acts like it is happy (so far; did not check dmesg or fdisk):
> 
> [root@problembox ~]# systemctl status iscsi
> o iscsi.service - Login and scanning of iSCSI devices
>Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; vendor 
> preset: disabled)
>Active: active (exited) since Thu 2021-11-25 23:21:40 EST; 9h ago
>  Docs: man:iscsiadm(8)
>man:iscsid(8)
>   Process: 3414 ExecStart=/usr/sbin/iscsiadm -m node --loginall=automatic 
> (code=exited, status=0/SUCCESS)
>  Main PID: 3414 (code=exited, status=0/SUCCESS)
> Tasks: 0 (limit: 203741)
>Memory: 0B
>CGroup: /system.slice/iscsi.service
> 
> Nov 25 23:17:52 problembox systemd[1]: Starting Login and scanning of iSCSI 
> devices...
> Nov 25 23:21:40 problembox iscsiadm[3414]: Logging in to [iface: default, 
> target: iqn.2000-01.com.synology-iSCSI:storage.01, portal: 
> 192.168.10.18,3260]
> Nov 25 23:21:40 problembox iscsiadm[3414]: Login to [iface: default, 
> target: iqn.2000-01.com.synology-iSCSI:storage.01, portal: 
> 192.168.10.18,3260] successful.
> Nov 25 23:21:40 problembox systemd[1]: Started Login and scanning of iSCSI 
> devices.
> [root@problembox ~]#
> 
> [root@problembox ~]# ls -lh /dev/sd*
> brw-rw. 1 root disk 8,  0 Nov 25 21:42 /dev/sda
> brw-rw. 1 root disk 8,  1 Nov 25 21:42 /dev/sda1
> brw-rw. 1 root disk 8,  2 Nov 25 21:42 /dev/sda2
> brw-rw. 1 root disk 8,  3 Nov 25 21:42 /dev/sda3
> brw-rw. 1 root disk 8, 16 Nov 25 23:33 /dev/sdb
> [root@problembox ~]# ls -l /dev/disk/by-path/|grep ip
> lrwxrwxrwx. 1 root root  9 Nov 25 23:33 
> ip-192.168.10.18:3260-iscsi-iqn.2000-01.com.synology-iSCSI:storage.01-lun-0 
> -> ../../sdb
> [root@problembox ~]#
> 
> Time to go probe the elephant in the room
> 
> [root@problembox ~]# fdisk -l /dev/sdb
> fdisk: cannot open /dev/sdb: Input/output error
> [root@problembox ~]#
> 
> What does dmesg has to tell me? The expected behaviour as seen in the 
> testbox (mounting the very same LUN):
> 
> [root@testbox ~]# dmesg -T
> [...]
> [Thu Nov 25 19:58:00 2021] Loading iSCSI transport class v2.0-870.
> [Thu Nov 25 19:58:00 2021] iscsi: registered transport (tcp)
> [Thu Nov 25 19:58:00 2021] scsi host2: iSCSI Initiator over TCP/IP
> [Thu Nov 25 19:58:00 2021] scsi 2:0:0:0: Direct-Access SYNOLOGY iSCSI 
> Storage3.1  PQ: 0 ANSI: 5
> [Thu Nov 25 19:58:00 2021] scsi 2:0:0:0: alua: supports implicit TPGS
> [Thu Nov 25 19:58:00 2021] scsi 2:0:0:0: alua: device 
> naa.6001405e61f8c59d35fdd4481da3e1d3 port group 1 rel port 1
> [Thu Nov 25 19:58:00 2021] scsi 2:0:0:0: Attached scsi generic sg1 type 0
> [Thu Nov 25 19:58:00 2021] scsi 2:0:0:0: alua: transition timeout set to 60 
> seconds
> [Thu Nov 25 19:58:00 2021] scsi 2:0:0:0: alua: port group 01 state A 
> non-preferred supports TOlUSNA
> [Thu Nov 25 19:58:00 2021] sd 2:0:0:0: [sda] 754974720 512-byte logical 
> blocks: (387 GB/360 GiB)
> [Thu Nov 25 19:58:00 2021] sd 2:0:0:0: [sda] Write Protect is off
> [Thu Nov 25 19:58:00 2021] sd 2:0:0:0: [sda] Mode Sense: 3b 00 00 00
> [Thu Nov 25 19:58:00 2021] sd 2:0:0:0: [sda] Write cache: disabled, read 
> cache: enabled, doesn't support DPO or FUA
> [Thu Nov 25 19:58:00 2021]  sda: sda1
> [Thu Nov 25 19:58:00 2021] sd 2:0:0:0: [sda] Attached SCSI disk
> [root@testbox ~]#

Did you notice: You are testing sdb, but the messages above are for sda!

> 
> Behaviour seen in the problembox
> 
> [root@problembox ~]# dmesg -T
> [Thu Nov 25 23:17:51 2021] scsi host8: iSCSI Initiator over TCP/IP
> [Thu Nov 25 23:17:51 2021] scsi 8:0:0:0: Direct-Access SYNOLOGY iSCSI 
> Storage3.1  PQ: 0 ANSI: 5
> [Thu Nov 25 23:17:51 2021] scsi 8:0:0:0: alua: supports implicit TPGS
> [Thu Nov 25 23:17:51 2021] scsi 8:0:0:0: alua: device 
> naa.6001405e61f8c59d35fdd4481da3e1d3 port group 1 rel port 1
> [Thu Nov 25 23:17:51 2021] sd 8:0:0:0: Attached scsi generic sg1 type 0
> [Thu Nov 25 23:18:02 2021]  connection4:0: ping timeout of 5 secs expired, 
> recv timeout 5, last rx 4300399244, last ping 4300404736, now 4300409856
> [Thu Nov 25 23:18:02 2021]  connection4:0: detected conn error (1022)
> [...]
> [Thu Nov 25 23:31:56 2021]  connection4:0: detected conn error (1022)
> [Thu Nov 25 23:31:56 2021] sd 8:0:0:0: [sdb] tag#76 FAILED Result: 
> hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=72s
> [Thu Nov 25 23:31:56 2021] sd 8:0:0:0: [sdb] tag#76 CDB: Read(10) 28 00 2c 
> ff ff 80 00 00 08 00
> [Thu Nov 25 23:31:56 2021] blk_update_request: I/O error, dev sdb, sector 
> 

Antw: Re: [EXT] Concurrent usage of iscsiadm

[Ulrich Windl]

>>> The Lee-Man  schrieb am 21.10.2021 um 17:55 in
Nachricht <8d711f1e-d3f4-4109-87ed-a950e93298...@googlegroups.com>:
> Hi Ulrich:
> 
> I don't see how systemd is going to run parallel iscsiadm commands, at 
> least with the units that come with open-iscsi. Systemd actually guards 
> against that.

Actually my statement was not specific to iscsiadm, but general: If serveral 
systemd services depend on one systemd target, those services are started in 
parallel (unless other conditions prevent that) when that target is to be 
reached.

> 
> As far as locking, I'd be glad to entertain/discuss/review patches that 
> make iscsiadm behave well when run in parallel. But such as change isn't on 
> my short list of things to work on, since I don't really see the need. I'd 
> rather focus on making iscsid play well in containers.
> 
> On Wednesday, October 20, 2021 at 11:19:24 PM UTC-7 Uli wrote:
> 
>> Hi!
>>
>> Another thing is: Whether you like systemd or not: It runs many processes 
>> automatically and concurrently.
>> So it seems wise that iscasadm may be run concurrently. If there are 
>> issues, iscsiadm should use a MUTEX internally to avoid those IMHO
>>
>> Regards,
>> Ulrich
>> >>> Vojtech Juranek  schrieb am 20.10.2021 um 08:58 in
>> Nachricht <4882593.9...@localhost.localdomain>:
>> > Hi,
>> > I'd like to follow up with discussion about concurrent usage iscsiadm 
>> tool. 
>> > It 
>> > was discussed here about year ago, with suggestion not to use it 
>> > concurrently 
>> > [1]. On the other hand, comment [2] says it should be fine. Is the an 
>> > agreement 
>> > in open-iscsi community if the concurrent usage of iscsiadm is safe or 
>> not? 
>> > If 
>> > it's not safe, is there any bug for open-iscsi describing the issue and 
>> > potential problems if iscsiadm is used concurrently?
>> > 
>> > The motivation why I'm popping up this again is that in oVirt project 
>> [3] we 
>> > 
>> > use a lock before calling iscsiadm to make sure it's not run in 
>> parallel. 
>> > This 
>> > causes us various issues (see e.g. BZ #1787192 [2]) and we'd like to get 
>> rid 
>> > 
>> > off this lock.
>> > 
>> > I run several thousands tests with our typical usage of iscsiadm [4], 
>> > running 
>> > iscsiadm in parallel and haven't spot any issue so far. This suggests 
>> > removing 
>> > the lock can be safe, but of course my tests could be just a pure luck. 
>> So 
>> > before removing this lock from our code base, I'd like to know your 
>> thoughts 
>> > 
>> > about it.
>> > 
>> > Thanks
>> > Vojta
>> > 
>> > [1] https://groups.google.com/g/open-iscsi/c/OHOdIm1W274/m/9l5NcPQHBAAJ 
>> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1787192#c18 
>> > [3] https://www.ovirt.org/ 
>> > [4] https://github.com/oVirt/vdsm/blob/master/tests/storage/stress/ 
>> > initiator.py
>> > 
>> > -- 
>> > 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.
>> > To view this discussion on the web visit 
>> > 
>> 
> https://groups.google.com/d/msgid/open-iscsi/4882593.9CP3fYhb5E%40localhost.l 
> 
>> > ocaldomain.
>>
>>
>>
>>
>>
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/8d711f1e-d3f4-4109-87ed-a950e932 
> 9895n%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6172782702A100044BFD%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Concurrent usage of iscsiadm

[Ulrich Windl]

Hi!

Another thing is: Whether you like systemd or not: It runs many processes 
automatically and concurrently.
So it seems wise that iscasadm may be run concurrently. If there are issues, 
iscsiadm should use a MUTEX internally to avoid those IMHO

Regards,
Ulrich
>>> Vojtech Juranek  schrieb am 20.10.2021 um 08:58 in
Nachricht <4882593.9CP3fYhb5E@localhost.localdomain>:
> Hi,
> I'd like to follow up with discussion about concurrent usage iscsiadm tool. 
> It 
> was discussed here about year ago, with suggestion not to use it 
> concurrently 
> [1]. On the other hand, comment [2] says it should be fine. Is the an 
> agreement 
> in open-iscsi community if the concurrent usage of iscsiadm is safe or not? 
> If 
> it's not safe, is there any bug for open-iscsi describing the issue and 
> potential problems if iscsiadm is used concurrently?
> 
> The motivation why I'm popping up this again is that in oVirt project [3] we 
> 
> use a lock before calling iscsiadm to make sure it's not run in parallel. 
> This 
> causes us various issues (see e.g. BZ #1787192 [2]) and we'd like to get rid 
> 
> off this lock.
> 
> I run several thousands tests with our typical usage of iscsiadm [4], 
> running 
> iscsiadm in parallel and haven't spot any issue so far. This suggests 
> removing 
> the lock can be safe, but of course my tests could be just a pure luck. So 
> before removing this lock from our code base, I'd like to know your thoughts 
> 
> about it.
> 
> Thanks
> Vojta
> 
> [1] https://groups.google.com/g/open-iscsi/c/OHOdIm1W274/m/9l5NcPQHBAAJ 
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1787192#c18 
> [3] https://www.ovirt.org/ 
> [4] https://github.com/oVirt/vdsm/blob/master/tests/storage/stress/ 
> initiator.py
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/4882593.9CP3fYhb5E%40localhost.l 
> ocaldomain.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6171066602A100044B4B%40gwsmtp.uni-regensburg.de.

Re: Antw: [EXT] Re: [PATCH] scsi scsi_transport_iscsi.c: fix misuse of %llu in scsi_transport_iscsi.c

[Ulrich Windl]

>>> Mike Christie  schrieb am 11.10.2021 um 17:29 
>>> in
Nachricht :
> On 10/11/21 1:35 AM, Ulrich Windl wrote:
>>>>> Joe Perches  schrieb am 09.10.2021 um 05:14 in Nachricht
>> <5daf69b365e23ceecee911c4d0f2f66a0b9ec95c.ca...@perches.com>:
>>> On Sat, 2021-10-09 at 11:02 +0800, Guo Zhi wrote:
>>>> Pointers should be printed with %p or %px rather than
>>>> cast to (unsigned long long) and printed with %llu.
>>>> Change %llu to %p to print the pointer into sysfs.
>>> ][]
>>>> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
>>> b/drivers/scsi/scsi_transport_iscsi.c
>>> []
>>>> @@ -129,8 +129,8 @@ show_transport_handle(struct device *dev, struct 
>>> device_attribute *attr,
>>>>  
>>>>
>>>>if (!capable(CAP_SYS_ADMIN))
>>>>return -EACCES;
>>>> -  return sysfs_emit(buf, "%llu\n",
>>>> -(unsigned long long)iscsi_handle(priv->iscsi_transport));
>>>> +  return sysfs_emit(buf, "%p\n",
>>>> +  iscsi_ptr(priv->iscsi_transport));
>>>
>>> iscsi_transport is a pointer isn't it?
>>>
>>> so why not just
>>>
>>> return sysfs_emit(buf, "%p\n", priv->iscsi_transport);
>> 
>> Isn't the difference that %p outputs hex, while %u outputs decimal?
>> 
> 
> Yeah, I think this patch will break userspace, because it doesn't know it's
> a pointer. It could be doing:
> 
> sscanf(str, "%llu", );
> 
> The value is just later passed back to the kernel to look up a driver in
> iscsi_if_transport_lookup:
> 
> list_for_each_entry(priv, _transports, list) {
> if (tt == priv->iscsi_transport) {
> 
> so we could just replace priv->transport with an int and use an ida to assign
> the value.

I'm not in the details, but if that value is used as an ID, shouldn't it have 
been something like "ID%llu" right from the start?
If so it would be rather easy to use "ID%p" instead (if the syntax of the ID is 
left unspecified). At least nobody would treat it as a number.

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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/ae7a82c2-5b19-493a-8d61-cdccb00c 
> f46c%40oracle.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6165337C02A1000446A6%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: [PATCH] scsi scsi_transport_iscsi.c: fix misuse of %llu in scsi_transport_iscsi.c

[Ulrich Windl]

>>> Joe Perches  schrieb am 09.10.2021 um 05:14 in Nachricht
<5daf69b365e23ceecee911c4d0f2f66a0b9ec95c.ca...@perches.com>:
> On Sat, 2021-10-09 at 11:02 +0800, Guo Zhi wrote:
>> Pointers should be printed with %p or %px rather than
>> cast to (unsigned long long) and printed with %llu.
>> Change %llu to %p to print the pointer into sysfs.
> ][]
>> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> []
>> @@ -129,8 +129,8 @@ show_transport_handle(struct device *dev, struct 
> device_attribute *attr,
>>  
>> 
>>  if (!capable(CAP_SYS_ADMIN))
>>  return -EACCES;
>> -return sysfs_emit(buf, "%llu\n",
>> -  (unsigned long long)iscsi_handle(priv->iscsi_transport));
>> +return sysfs_emit(buf, "%p\n",
>> +iscsi_ptr(priv->iscsi_transport));
> 
> iscsi_transport is a pointer isn't it?
> 
> so why not just
> 
>   return sysfs_emit(buf, "%p\n", priv->iscsi_transport);

Isn't the difference that %p outputs hex, while %u outputs decimal?

> 
> ?
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/5daf69b365e23ceecee911c4d0f2f66a 
> 0b9ec95c.camel%40perches.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6163DB2E02A1000445F1%40gwsmtp.uni-regensburg.de.

Antw: [EXT] linux iscsi target setup for IP camera

[Ulrich Windl]

I think at the very least you'll have to provide some details (like logs from 
Linux, and maybe some details from Windows where it is said to work).
Or a technical specification of the camera at least.

Regards,
Ulrich

>>> Fernando Perfumo  schrieb am 26.08.2021 um 16:44 in 
>>> Nachricht
:

> I'm trying to set up iscsi target on Debian 11 for recording video from 
> Bosch ip cameras.
> 
> I can connect to the target from windows, but not from the cameras.
> 
> tcpdump shows in the negotiation's packets the presence of "X-" parameters 
> on the camera TCP packets.
> I've seen in the iscsi RFC these extra parameters are optional.
> 
> Does somebody knows if the existence of "X-" parameters can break the 
> negotiation of targets and luns on iscsi linux implemetations?
> 
> There is no more references to X- and X# parameters on internet except on 
> the original iscsi RFC, else I would have found some. 
> 
> I want to modify the iscsi sources to allow admins to test and supply 
> convenient responses to 'X-com.whatever' maker's parameters, and I would 
> appreciate your suggestions.
> 
> I've heard these ip cameras work too with microsoft's iscsi -non bosch 
> altered- target implementations, so it may be only matter of supplying 
> convenient responses to X- parameters.
> 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/a410c8bc-f3d7-4d6a-a6d5-f8dbdcd6 
> 2d41n%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/612887D502A100043866%40gwsmtp.uni-regensburg.de.

Re: Antw: [EXT] ISCSI Target and Initiator on same host

[Ulrich Windl]

>>> Riaan Pretorius  schrieb am 30.06.2021 um 
>>> 17:15
in Nachricht :
> I get strange messages in my logs when i tried do that. and get disk 
> "flapping" when the disk just appear and reappear continuously after a 
> reboot.   logically it would make sense that you can do this, but 
> practically  there is weird issues. Would you guys say it might be a 
> misconfiguration ?

Maybe be concrete with your setup and messages first.

> 
> On Wednesday, 30 June 2021 at 15:10:54 UTC+2 Paul Koning wrote:
> 
>>
>>
>> > On Jun 30, 2021, at 7:29 AM, Ulrich Windl <
>> ulrich...@rz.uni-regensburg.de> wrote:
>> > 
>> > I think I did that about 10 years ago...
>> > 
>> >>>> Riaan Pretorius  schrieb am 30.06.2021 um 
>> 12:41
>> > in Nachricht <07b30064-72b3-42c1...@googlegroups.com>:
>> >> I have an interesting question to ask:
>> >> 
>> >> Is it possible to share the target on the same server as a initiator ?
>> >> e.g. server1: target -> server1: initiator 
>>
>> Yes, I've used that in a test setup when I needed to put a file system on 
>> iSCSI (to test pNFS).
>>
>> paul
>>
>>
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/f3e8a3df-cfb2-4913-b518-e01a8016 
> 14dbn%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/60DD5CB102A100042184%40gwsmtp.uni-regensburg.de.

Antw: [EXT] ISCSI Target and Initiator on same host

[Ulrich Windl]

I think I did that about 10 years ago...

>>> Riaan Pretorius  schrieb am 30.06.2021 um 
>>> 12:41
in Nachricht <07b30064-72b3-42c1-ae71-f40c885c06...@googlegroups.com>:
> I have an interesting question to ask:
> 
> Is it possible to share the target on the same server as a initiator ?
> e.g. server1: target -> server1: initiator 
> 
> And then share:
> server1: target > server2: initiator 
> 
> 
> The idea here it it is sharing a lun to the target itself and other 
> servers. The intention is to use it with oracle RAC. 
> 
> Something like this possible with ISCSI?
> 
> maybe not the right forum to ask, but asking the creators might get a 
> better answer
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/07b30064-72b3-42c1-ae71-f40c885c 
> 06ffn%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/60DC55B502A100042163%40gwsmtp.uni-regensburg.de.

Aw: [EXT] Re: [PATCH 1/1] scsi: Fix spelling mistakes in header files

[Ulrich Windl]

(Amazingly I also did think "busses" is correct -- seems to be a common 
mistake; maybe only for Germans that would pronounce "busses" differently from 
"buses"...)


>>> Martin K. Petersen 26.05.2021, 06:08 >>>

On Mon, 17 May 2021 17:59:45 +0800, Zhen Lei wrote:

> Fix some spelling mistakes in comments:
> pathes ==> paths
> Resouce ==> Resource
> retreived ==> retrieved
> keep-alives ==> keep-alive
> recevied ==> received
> busses ==> buses
> interruped ==> interrupted

Applied to 5.14/scsi-queue, thanks!

[1/1] scsi: Fix spelling mistakes in header files
https://git.kernel.org/mkp/scsi/c/40d6b939e4df

--
Martin K. Petersen Oracle Linux Engineering

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/162200196243.11962.5629932935575912565.b4-ty%40oracle.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/60AE227202A100041478%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH AUTOSEL 5.11 07/22] scsi: iscsi: Fix race condition between login and sync thread

[Ulrich Windl]

>>> Sasha Levin  schrieb am 05.04.2021 um 18:03 in Nachricht
<20210405160406.268132-7-sas...@kernel.org>:
> @@ -2963,6 +2971,7 @@ static int iscsi_if_ep_disconnect(struct 
> iscsi_transport *transport,
>   mutex_lock(>ep_mutex);
>   conn->ep = NULL;
>   mutex_unlock(>ep_mutex);
> + conn->state = ISCSI_CONN_DOWN;
>   }

I just wonder: Why do you set the CONN_DOWN outside of the MUTEX?


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/606C272C02A1000402F9%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Hi help me please

[Ulrich Windl]

>>> go xayyasang  schrieb am 06.12.2020 um 15:38 in
Nachricht :
> [root@target ~]# iscsiadm -m node -o show
> iscsiadm: No records found

Hi!

Obviously something is not as you expect. Without knowing details, nobody can 
help you.
Please take the time to explain what you did and what you do expect. Details, 
please!

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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/dd922e70-a4b0-4d61-aed1-ef8eca28 
> 7926n%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5FDB069902A10003D9DF%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH 05/12] open-iscsi: Fix NULL pointer dereference in mgmt_ipc_read_req()

[Ulrich Windl]

>>> Wenchao Hao  schrieb am 07.12.2020 um 02:54 in 
>>> Nachricht
<20201207015410.48488-6-haowenc...@huawei.com>:
> If malloc() returns NULL on fail, we should return -ENOMEM to
> avoid NULL pointer dereference.
> 
> Signed-off-by: Wenchao Hao 
> Signed-off-by: Zhiqiang Liu 
> Signed-off-by: Wu Bo 
> ---
>  usr/mgmt_ipc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/usr/mgmt_ipc.c b/usr/mgmt_ipc.c
> index c292161..054378e 100644
> --- a/usr/mgmt_ipc.c
> +++ b/usr/mgmt_ipc.c
> @@ -453,8 +453,11 @@ mgmt_ipc_read_req(queue_task_t *qtask)
>   /* Remember the allocated pointer in the
>* qtask - it will be freed by write_rsp.
>* Note: we allocate one byte in excess
> -  * so we can append a NUL byte. */
> +  * so we can append a NULL byte. */

Nitpick: "NUL" is a well-defined ACSII character, while NULL is a well-defined 
C pointer. Thus I'd keep NUL.

>   qtask->payload = malloc(req->payload_len + 1);
> + if (!qtask->payload)
> + return -ENOMEM;
> +
>   rc = mgmt_ipc_read_data(qtask->mgmt_ipc_fd,
>   qtask->payload,
>   req->payload_len);
> -- 
> 2.27.0
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to open-iscsi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/20201207015410.48488-6-haowencha 
> o%40huawei.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5FCF3A5F02A10003D5BB%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH] iscsiadm: Verify mode parameters when recognize mode

[Ulrich Windl]

>>> Wenchao Hao  schrieb am 20.11.2020 um 07:20 in 
>>> Nachricht
<20201120062052.51838-1-haowenc...@huawei.com>:
> Parameters verify should be performed as soon as possible
> to avoid unuseless work.

"avoid unuseless work" ;-)

Is that useful 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5FB77CC602A10003CD42%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH v2] SCSI: libiscsi: fix NOP race condition

[Ulrich Windl]

>>> Lee Duncan  schrieb am 06.11.2020 um 20:33 in
Nachricht <20201106193317.16993-1-leeman.dun...@gmail.com>:

...
> +/* invalid scsi_task pointer */
> +#define  INVALID_SCSI_TASK   (struct iscsi_task *)-1l
...

Comment: I prefer 'L' over 'l', because in many fonts 'I', '1' and 'l' look 
very similar ('I' is not a problem here, however).

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5FA8F2BF02A10003C905%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: Slow iSCSI tape performance

[Ulrich Windl]

>>> The Lee-Man  schrieb am 25.10.2020 um 17:51 in
Nachricht <4ad354c3-5d6a-4b1f-b978-afee5d1219...@googlegroups.com>:
> I haven't heard about disabling TUR for iSCSI tape improvement. Even if 
> true, I'm not sure how you'd do that. You'd need to modify your target IMHO 
> to always reply "ready" for TUR. But TUR is used to clear some conditions 
> at the target, if present, so not sure about the semantics of ignoring 
> TURs. Have you tried setting the streaming bit for the tape drive?
> 
> On Wednesday, October 21, 2020 at 6:43:22 AM UTC-7 david.p...@perdrix.co.uk 
> wrote:
> 
>> I've seen a report that disabling Test Unit Ready across the iSCSI link 
>> can hugely improve performance of remote tape drives.

Bit isn't it as slow _with_ iSCSI as it is _without_? My guess is that a TUR in 
the middle of a tape rewind will respond after the current command has 
completed.

>>
>> Is this something I do at the machine hosting the tape drive or at the 
>> client?
>>
>> Is it relevant to open iscsi?
>>
>> Thanks
>> David
>>
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/4ad354c3-5d6a-4b1f-b978-afee5d12 
> 19aen%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5F9681C902A10003C2F4%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

[Ulrich Windl]

>>> Mike Christie  schrieb am 08.10.2020 um 22:54 
>>> in
Nachricht <47eca384-b54e-63cc-0f84-7ed6501f4...@oracle.com>:
> On 10/8/20 12:11 PM, Mike Christie wrote:
>> On 9/25/20 1:41 PM, ldun...@suse.com wrote:
>>> From: Lee Duncan 
>>>
>>> iSCSI NOPs are sometimes "lost", mistakenly sent to the
>>> user-land iscsid daemon instead of handled in the kernel,
>>> as they should be, resulting in a message from the daemon like:
>>>
 iscsid: Got nop in, but kernel supports nop handling.
>>>
>>> This can occur because of the forward- and back-locks
>>> in the kernel iSCSI code, and the fact that an iSCSI NOP
>>> response can be processed before processing of the NOP send
>>> is complete. This can result in "conn->ping_task" being NULL
>>> in iscsi_nop_out_rsp(), when the pointer is actually in
>>> the process of being set.
>>>
>>> To work around this, we add a new state to the "ping_task"
>>> pointer. In addition to NULL (not assigned) and a pointer
>>> (assigned), we add the state "being set", which is signaled
>>> with an INVALID pointer (using "-1").
>>>
>>> Signed-off-by: Lee Duncan 
>>> ---
>>>  drivers/scsi/libiscsi.c | 13 ++---
>>>  include/scsi/libiscsi.h |  3 +++
>>>  2 files changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>>> index 1e9c3171fa9f..cade108c33b6 100644
>>> --- a/drivers/scsi/libiscsi.c
>>> +++ b/drivers/scsi/libiscsi.c
>>> @@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
> iscsi_hdr *hdr,
>>>task->conn->session->age);
>>> }
>>>  
>>> +   if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
>>> +   WRITE_ONCE(conn->ping_task, task);
>>> +
>>> if (!ihost->workq) {
>>> if (iscsi_prep_mgmt_task(conn, task))
>>> goto free_task;
>> 
>> I think the API gets a little weird now where in some cases
>> __iscsi_conn_send_pdu checks the opcode to see what type of request
>> it is but above we the caller sets the ping_task.
>> 
>> For login, tmfs and passthrough, we assume the __iscsi_conn_send_pdu
>> has sent or cleaned up everything. I think it might be nicer to just
>> have __iscsi_conn_send_pdu set the ping_task field before doing the
>> xmit/queue call. It would then work similar to the conn->login_task
>> case where that function knows about that special task too.
>> 
>> So in __iscsi_conn_send_pdu add a "if (opcode == ISCSI_OP_NOOP_OUT)",
>> and check if it's a nop we need to track. If so set conn->ping_task.
>> 
> Ignore this. It won't work nicely either. To figure out if the nop is
> our internal transport test ping vs a userspace ping that also needs
> a reply, we would need to do something like you did above so there is
> no point.

I don't know the implementation details, but if ICMP package data would contain 
some "unlikely" value for iSCSI pings, you could use the packet data to decide. 
I guess 32 random bits could be "unlikely enough".

> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/47eca384-b54e-63cc-0f84-7ed6501f 
> 427e%40oracle.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5F80105002A10003BD6F%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH v9 2/7] net: add WARN_ONCE in kernel_sendpage() for improper zero-copy send

[Ulrich Windl]

>>> Coly Li  schrieb am 01.10.2020 um 09:54 in Nachricht
<20201001075408.25508-3-col...@suse.de>:
> If a page sent into kernel_sendpage() is a slab page or it doesn't have
> ref_count, this page is improper to send by the zero copy sendpage()
> method. Otherwise such page might be unexpected released in network code

s/unexpected/unexpectedly/

> path and causes impredictable panic due to kernel memory management data
> structure corruption.
> 
> This path adds a WARN_ON() on the sending page before sends it into the
> concrete zero-copy sendpage() method, if the page is improper for the
> zero-copy sendpage() method, a warning message can be observed before
> the consequential unpredictable kernel panic.
> 
> This patch does not change existing kernel_sendpage() behavior for the
> improper page zero-copy send, it just provides hint warning message for
> following potential panic due the kernel memory heap corruption.
> 
> Signed-off-by: Coly Li 
> Cc: Cong Wang 
> Cc: Christoph Hellwig 
> Cc: David S. Miller 
> Cc: Sridhar Samudrala 
...


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5F758F0102A10003BACF%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH v6 1/6] net: introduce helper sendpage_ok() in include/linux/net.h

[Ulrich Windl]

>>> Coly Li  schrieb am 18.08.2020 um 14:47 in Nachricht
<20200818124736.5790-2-col...@suse.de>:
> The original problem was from nvme-over-tcp code, who mistakenly uses
> kernel_sendpage() to send pages allocated by __get_free_pages() without
> __GFP_COMP flag. Such pages don't have refcount (page_count is 0) on
> tail pages, sending them by kernel_sendpage() may trigger a kernel panic
> from a corrupted kernel heap, because these pages are incorrectly freed
> in network stack as page_count 0 pages.
> 
> This patch introduces a helper sendpage_ok(), it returns true if the
> checking page,
> - is not slab page: PageSlab(page) is false.
> - has page refcount: page_count(page) is not zero
> 
> All drivers who want to send page to remote end by kernel_sendpage()
> may use this helper to check whether the page is OK. If the helper does
> not return true, the driver should try other non sendpage method (e.g.
> sock_no_sendpage()) to handle the page.
> 
> Signed-off-by: Coly Li 
> Cc: Chaitanya Kulkarni 
> Cc: Christoph Hellwig 
> Cc: Hannes Reinecke 
> Cc: Jan Kara 
> Cc: Jens Axboe 
> Cc: Mikhail Skorzhinskii 
> Cc: Philipp Reisner 
> Cc: Sagi Grimberg 
> Cc: Vlastimil Babka 
> Cc: sta...@vger.kernel.org 
> ---
>  include/linux/net.h | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/include/linux/net.h b/include/linux/net.h
> index d48ff1180879..a807fad31958 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -286,6 +287,21 @@ do { 
> \
>  #define net_get_random_once_wait(buf, nbytes)\
>   get_random_once_wait((buf), (nbytes))
>  
> +/*
> + * E.g. XFS meta- & log-data is in slab pages, or bcache meta
> + * data pages, or other high order pages allocated by
> + * __get_free_pages() without __GFP_COMP, which have a page_count
> + * of 0 and/or have PageSlab() set. We cannot use send_page for
> + * those, as that does get_page(); put_page(); and would cause
> + * either a VM_BUG directly, or __page_cache_release a page that
> + * would actually still be referenced by someone, leading to some
> + * obscure delayed Oops somewhere else.
> + */

Actually I think this comment is somewhat mis-placed:
It should describe what the function does (check for specific properties of a 
page), but not where this function might be used. Most notably, because the use 
(from where it is called) may change over time, while the function will still 
do the same thing.

> +static inline bool sendpage_ok(struct page *page)
> +{
> + return  (!PageSlab(page) && page_count(page) >= 1);
> +}
> +
>  int kernel_sendmsg(struct socket *sock, struct msghdr *msg, struct kvec 
> *vec,
>  size_t num, size_t len);
>  int kernel_sendmsg_locked(struct sock *sk, struct msghdr *msg,
> -- 
> 2.26.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/20200818124736.5790-2-colyli%40s 
> use.de.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5F3CBF5302A10003AB07%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: Large Immediate and/or Unsolicted Data causes long delays on R2T responses

[Ulrich Windl]

>>> The Lee-Man  schrieb am 29.06.2020 um 20:59 in
Nachricht
<4792_1593457181_5EFA3A1C_4792_1489_1_4c70b62c-467c-4860-a951-663fb88158c7o@goog
egroups.com>:
> On Saturday, May 2, 2020 at 11:30:27 AM UTC-7, ajhutc...@gmail.com wrote:
>>
>> I am able to create a condition where the open-iscsi initiator fails to 
>> respond to an R2T request if the immediate/unsolicited data support is 
>> large ~128KB.  I've seen instances where a delay on an R2T is only a few 
>> seconds and other instances where no response is received in 180 seconds.
>>
>> If the host is doing a prefill operation with large writes that can be 
>> completed with immediate data alone and a large write that requires an R2T 
>> is sent, the open-iscsi initiator sometimes fails to respond to the 
>> target's R2T. 
>>
>> After inspecting the code, I am convinced it is caused by the lack of 
>> fairness in the *libiscsi  **iscsi_data_xmit* routine, which always 
>> favors the sending a new command over responding to R2Ts. 
>>
>> /**
>>  * iscsi_data_xmit - xmit any command into the scheduled connection
>>  * @conn: iscsi connection
>>  *
>>  * Notes:
>>  * The function can return -EAGAIN in which case the caller must
>>  * re-schedule it again later or recover. '0' return code means
>>  * successful xmit.
>>  **/
>> static int iscsi_data_xmit(struct iscsi_conn *conn)
>> {
>> ...
>> /*
>> * process mgmt pdus like nops before commands since we should
>> * only have one nop-out as a ping from us and targets should not
>> * overflow us with nop-ins
>> */
>> while (!list_empty(>mgmtqueue)) {
>> ...
>> /* process pending command queue */
>> while (!list_empty(>cmdqueue)) {
>> ...
>> while (!list_empty(>requeue)) {
>>
>>
>> Am I looking at this code correctly?  I guess this order might be better 
>> for parallelization at the target by getting more commands onboard before 
>> responding to outstanding R2Ts. With immediate/unsolicited data enabled, 
>> the overhead of transmitting a new commands if higher and probably 
>> shouldn't come before responding to R2Ts. 
>>
>>
>> Do you have NOPs enabled? If so, do you see this issue with them disabled? 
> I seriously dislike and advise against NOPs. I've never seen them actually 
> help anything.

They could keep an connection alive that is passing through some firewall when 
there is no iSCSI I/O, maybe.

> 
> Have you tried playing with this code, i.e. changing the order? Without 
> looking deeply, are the R2Ts in the command queue and not in the requeue 
> queue?
> 
> What kind of load are you presenting to the server?
> 
> What do you mean by "the immediate/unsolicited data support is large 
> ~128KB"? What setting(s) did you change?
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/4c70b62c-467c-4860-a951-663fb881 
> 58c7o%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5EFADD5D02A100039CE2%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH] iscsi: Add break to while loop

[Ulrich Windl]

>>> Wu Bo  schrieb am 04.06.2020 um 14:23 in Nachricht
<7784_1591272646_5ED8E4C6_7784_490_1_1591273415-689835-1-git-send-email-wubo40@h
awei.com>:
> From: liubo 
> 
> Fix the potential risk of rc value being washed out by jumping out of the 
> loop
> 
> Signed-off-by: liubo 
> Reported-by: Zhiqiang Liu 
> ---
>  utils/fwparam_ibft/fwparam_sysfs.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/utils/fwparam_ibft/fwparam_sysfs.c 
> b/utils/fwparam_ibft/fwparam_sysfs.c
> index a0cd1c7..87fd6d4 100644
> --- a/utils/fwparam_ibft/fwparam_sysfs.c
> +++ b/utils/fwparam_ibft/fwparam_sysfs.c
> @@ -115,8 +115,11 @@ static int get_iface_from_device(char *id, struct 
> boot_context *context)
>   break;
>   }
>  
> - if (sscanf(dent->d_name, "net:%s", context->iface) != 1)
> + if (sscanf(dent->d_name, "net:%s", context->iface) != 
> 1) {
>   rc = EINVAL;
> + break;
> + }
> +
>   rc = 0;
>   break;
>   } else {
> -- 
> 2.21.0.windows.1

It seems to me the whole code could be more readable if the rc were preset 
either to "success" (0) or "error" (something else), and if the "other" result 
is needed just set the desired rc. Those multiple "break"s make the code hard 
to read.


> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/1591273415-689835-1-git-send-ema 
> il-wubo40%40huawei.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5ED9087A02A100039500%40gwsmtp.uni-regensburg.de.

Antw: [EXT] Re: udev events for iscsi

[Ulrich Windl]

>>> Donald Williams  schrieb am 21.04.2020 um 20:49 in
Nachricht
<30147_1587494977_5E9F4041_30147_801_1_CAK3e-EawwxYGb3Gw74+P-yBmrnE0ktOL=Fj1OT_L
q+czyz...@mail.gmail.com>:
> Hello,
> 
>  If the loss exceeds the timeout value yes.  If the 'drive' doesn't come
> back in 30 to 60 seconds it's not likely a transitory event like a cable
> pull.
> 
> NOOP-IN and NOOP-OUT are also know as KeepAlive.  That's when the

Actually I think that's two different mechanisms: Keepalive just prevents the 
connection from being discarded (some firewall like to do that), while the 
No_op actually is an end-to-end (almost at least) connection test.

> connection is up but the target or initiator isn't responding.   If those
> timeout the connection will be dropped and a new connection attempt made.

I think the original intention for SCSI timeouts was to conclude a device has 
failed if it does not respond within time (actually there are different 
timeouts depending on the operation (like the famous rewinding of a long 
tape)). Next step for the OS would be to block I/O to a seemingly failed 
device. Recent operating systems like Linux have the choice to remove the 
device logically, requiring it to re-appear before it can be used. In some 
cases it seems preferrable to keep the device, because otherwise there could be 
a cascading effect like killing processes that have the device open (UNIX 
processes do not like it when opened devices suddenly disappear).

Regards,
Ulrich

> 
>  Don
> 
> 
> On Tue, Apr 21, 2020 at 2:44 PM The Lee-Man  wrote:
> 
>> On Tuesday, April 21, 2020 at 12:31:24 AM UTC-7, Gionatan Danti wrote:
>>>
>>> [reposting, as the previous one seems to be lost]
>>>
>>> Hi all,
>>> I have a question regarding udev events when using iscsi disks.
>>>
>>> By using "udevadm monitor" I can see that events are generated when I
>>> login and logout from an iscsi portal/resource, creating/destroying the
>>> relative links under /dev/
>>>
>>> However, I can not see anything when the remote machine simple
>>> dies/reboots/disconnects: while "dmesg" shows the iscsi timeout expiring, I
>>> don't see anything about a removed disk (and the links under /dev/ remains
>>> unaltered, indeed). At the same time, when the remote machine and disk
>>> become available again, no reconnection events happen.
>>>
>>
>> Because of the design of iSCSI, there is no way for the initiator to know
>> the server has gone away. The only time an initiator might figure this out
>> is when it tries to communicate with the target.
>>
>> This assumes we are not using some sort of directory service, like iSNS,
>> which can send asynchronous notifications. But even then, the iSNS server
>> would have to somehow know that the target went down. If the target
>> crashed, that might be difficult to ascertain.
>>
>> So in the absence of some asynchronous notification, the initiator only
>> knows the target is not responding if it tries to talk to that target.
>>
>> Normally iscsid defaults to sending periodic NO-OPs to the target every 5
>> seconds. So if the target goes away, the initiator usually notices, even if
>> no regular I/O is occurring.
>>
>> But this is where the error recovery gets tricky, because iscsi tries to
>> handle "lossy" connections. What if the server will be right back? Maybe
>> it's rebooting? Maybe the cable will be plugged back in? So iscsi keeps
>> trying to reconnect. As a matter of fact, if you stop iscsid and restart
>> it, it sees the failed connection and retries it -- forever, by default. I
>> actually added a configuration parameter called reopen_max, that can limit
>> the number of retries. But there was pushback on changing the default value
>> from 0, which is "retry forever".
>>
>> So what exactly do you think the system should do when a connection "goes
>> away"? How long does it have to be gone to be considered gone for good? If
>> the target comes back "later" should it get the same disc name? Should we
>> retry, and if so how much before we give up? I'm interested in your views,
>> since it seems like a non-trivial problem to me.
>>
>>>
>>> I can read here that, years ago, a patch was in progress to give better
>>> integration with udev when a device disconnects/reconnects. Did the patch
>>> got merged? Or does the one I described above remain the expected behavior?
>>> Can be changed?
>>>
>>
>> So you're saying as soon as a bad connection is detected (perhaps by a
>> NOOP), the device should go away?
>>
>>>
>>> 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 view this discussion on the web visit
>> 
> https://groups.google.com/d/msgid/open-iscsi/7f583720-8a84-4872-8d1a-5cd28429 
> 5c22%40googlegroups.com
>> 
>   
> 

Antw: [EXT] Re: udev events for iscsi

[Ulrich Windl]

>>> The Lee-Man  schrieb am 21.04.2020 um 20:44 in
Nachricht
<618_1587494664_5E9F3F08_618_445_1_7f583720-8a84-4872-8d1a-5cd284295c22@googlegr
ups.com>:
> On Tuesday, April 21, 2020 at 12:31:24 AM UTC-7, Gionatan Danti wrote:
>>
>> [reposting, as the previous one seems to be lost]
>>
>> Hi all,
>> I have a question regarding udev events when using iscsi disks.
>>
>> By using "udevadm monitor" I can see that events are generated when I 
>> login and logout from an iscsi portal/resource, creating/destroying the 
>> relative links under /dev/
>>
>> However, I can not see anything when the remote machine simple 
>> dies/reboots/disconnects: while "dmesg" shows the iscsi timeout expiring, I 
>> don't see anything about a removed disk (and the links under /dev/ remains 
>> unaltered, indeed). At the same time, when the remote machine and disk 
>> become available again, no reconnection events happen.
>>
> 
> Because of the design of iSCSI, there is no way for the initiator to know 
> the server has gone away. The only time an initiator might figure this out 
> is when it tries to communicate with the target.

My knowlege of the SCSI stack is quite poor, but I think the last revisions of 
parallel SCSI (like Ultra 320 (or was it 160?)) had a concept of "domain 
validation". AFAIK the leatter meant measuring the quality of the wires, 
adjusting the transfer speed.
While basically SCSI assumes "the bus" won't go away magically, a future iSCSI 
standard might contain  regular "bus checks" to trigger recovery actions if the 
"bus" (network transport connection) seems to be gone.

> 
> This assumes we are not using some sort of directory service, like iSNS, 
> which can send asynchronous notifications. But even then, the iSNS server 
> would have to somehow know that the target went down. If the target 
> crashed, that might be difficult to ascertain.

To be picky: If the traget went down (like a classical failing SCSI disk), it 
could issue some attention message, but when the transport went down, no such 
message can be received. So I think there's a difference between "target down" 
(device not present, device fails to respond) and "bus down" (no communication 
possible any more). In the second case no assumptions can be made about the 
health of the traget device.

> 
> So in the absence of some asynchronous notification, the initiator only 
> knows the target is not responding if it tries to talk to that target.
> 
> Normally iscsid defaults to sending periodic NO-OPs to the target every 5 
> seconds. So if the target goes away, the initiator usually notices, even if 
> no regular I/O is occurring.

So the target went away, or the bus went down?

> 
> But this is where the error recovery gets tricky, because iscsi tries to 
> handle "lossy" connections. What if the server will be right back? Maybe 
> it's rebooting? Maybe the cable will be plugged back in? So iscsi keeps 
> trying to reconnect. As a matter of fact, if you stop iscsid and restart 
> it, it sees the failed connection and retries it -- forever, by default. I 
> actually added a configuration parameter called reopen_max, that can limit 
> the number of retries. But there was pushback on changing the default value 
> from 0, which is "retry forever".
> 
> So what exactly do you think the system should do when a connection "goes 
> away"? How long does it have to be gone to be considered gone for good? If 
> the target comes back "later" should it get the same disc name? Should we 
> retry, and if so how much before we give up? I'm interested in your views, 
> since it seems like a non-trivial problem to me.

IMHO a "bus down" is a critical event affecting _all_ devices on that bus, not 
just a single target. Well, it might be some extra noise if those other targets 
have no I/O outstanding, but it's better to know that the bus is down before 
initiating a transfer rather than concluding seconds later that the target 
seems unreachable for some reasons unknown.

> 
>>
>> I can read here that, years ago, a patch was in progress to give better 
>> integration with udev when a device disconnects/reconnects. Did the patch 
>> got merged? Or does the one I described above remain the expected behavior? 
>> Can be changed?
>>
> 
> So you're saying as soon as a bad connection is detected (perhaps by a 
> NOOP), the device should go away? 

Maybe the state should be similar to a device being in power-save mode: It's 
not accessible right now, but should be woke up ASAP. See my earlier comparison 
to NFS hard-mounts...

Regards,
Ulrich

> 
>>
>> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/7f583720-8a84-4872-8d1a-5cd28429 
> 5c22%40googlegroups.com.



-- 
You received this 

Antw: [EXT] Re: udev events for iscsi

[Ulrich Windl]

>>> Donald Williams  schrieb am 21.04.2020 um 18:06
in
Nachricht
<29812_1587485183_5E9F19FE_29812_432_1_CAK3e-EbA-d6NeDETJ0EMHeAw3HGko_uCB_f6gsiq
jmeeyz...@mail.gmail.com>:

[...]
> 
> The default setting for Linux is 30 seconds. This can be verified using the
> command:
> 
>  # for i in $(find /sys/devices/platform –name timeout ) ; do cat $i ; done
> 30 30

Two remarks on the command above:
1) the command contains an en-dash instead of a minus, so you get funny error
messages like this:
find: ‘–iname’: No such file or directory
find: ‘timeout’: No such file or directory

2) Even with the correct command, I get no matches here (SLES12)

However I see matches within
/sys/devices/pci* and /sys/class/firmware/timeout

[...]

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5E9FDF7F02A1000387BE%40gwsmtp.uni-regensburg.de.

Aw: [EXT] Re: udev events for iscsi

[Ulrich Windl]

>>>  21.04.2020, 17:20 >>>Wondering myself.> On
Apr 21, 2020, at 2:31 AM, Gionatan Danti  wrote:> >
> [reposting, as the previous one seems to be lost]> > Hi all,> I have a
question regarding udev events when using iscsi disks.> > By using "udevadm
monitor" I can see that events are generated when I login and logout from an
iscsi portal/resource, creating/destroying the relative links under /dev/So
running “udevadm monitor” on the initiator, you can see when a block device
becomes available locally.   > > However, I can not see anything when the
remote machine simple dies/reboots/disconnects: while "dmesg" shows the iscsi
timeout expiring, I don't see anything about a removed disk (and the links
under /dev/ remains unaltered, indeed). At the same time, when the remote
machine and disk become available again, no reconnection events happen.As
someone who has had an inordinate amount of experience with the iSCSi
connection breaking ( power outage, Network switch dies,  wrong ethernet cable
pulled, the target server machine hardware crashes, ...) in the middle of
production, the more info the better.   Udev event triggers would help.   I
wonder exactly how XenServer handles this as it itself seemed more resilient. 
XenServer host initiators  do something correct to recover and wonder how that
compares to the normal iSCSi initiator.   But unfortunately, XenServer
LVM-over-iSCSi  does not pass the message along to its Linux virtual drives and
VMs in the same way as Windows VMs.When the target drives became available
again,   MS Windows virtual machines would gracefully recover on their own.   
All Linux VM  filesystems went read only and those VM machines required
forceful  rebooting.   mount remount would not work. > > I can read here that,
years ago, a patch was in progress to give better integration with udev when a
device disconnects/reconnects. Did the patch got merged? Or does the one I
described above remain the expected behavior? Can be changed?> > 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 view
this discussion on the web visit
https://groups.google.com/d/msgid/open-iscsi/13d4c963-b633-4672-97d9-dd41eec5fb5b%40googlegroups.com.--
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 view this
discussion on the web visit
https://groups.google.com/d/msgid/open-iscsi/9D54680A-F97E-4465-BA6C-566562C5DC91%40eyeconsultantspc.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5E9F80B202A10003875F%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH] open-iscsi:Modify iSCSI shared memory permissions for logs

[Ulrich Windl]

Hi!

Maybe this could be made a symbolic constant, or even be made configurable.
The other interesting thing is that there are three seemingly very similar code 
fragements to create the shared memory, but each with a different size 
parameter (sizeof(struct logarea) vs. size vs. MAX_MSG_SIZE + sizeof(struct  
logmsg)) ;-)

Regards,
Ulrich

>>> Wu Bo  schrieb am 17.04.2020 um 11:08 in Nachricht
<6355_1587114536_5E997228_6355_294_1_d6a22a2f-3730-45ee-5256-8a8fe4b017bf@huawei
com>:
> Hi,
> 
> Iscsid log damon is responsible for reading data from shared memory
> and writing syslog. Iscsid is the root user group.
> Currently, it is not seen that non-root users need to read logs.
> The principle of minimizing the use of permissions, all the permissions 
> are changed from 644 to 600.
> 
> Signed-off-by: Wu Bo 
> ---
>   usr/log.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/usr/log.c b/usr/log.c
> index 6e16e7c..2fc1850 100644
> --- a/usr/log.c
> +++ b/usr/log.c
> @@ -73,7 +73,7 @@ static int logarea_init (int size)
>  logdbg(stderr,"enter logarea_init\n");
> 
>  if ((shmid = shmget(IPC_PRIVATE, sizeof(struct logarea),
> -   0644 | IPC_CREAT | IPC_EXCL)) == -1) {
> +   0600 | IPC_CREAT | IPC_EXCL)) == -1) {
>  syslog(LOG_ERR, "shmget logarea failed %d", errno);
>  return 1;
>  }
> @@ -93,7 +93,7 @@ static int logarea_init (int size)
>  size = DEFAULT_AREA_SIZE;
> 
>  if ((shmid = shmget(IPC_PRIVATE, size,
> -   0644 | IPC_CREAT | IPC_EXCL)) == -1) {
> +   0600 | IPC_CREAT | IPC_EXCL)) == -1) {
>  syslog(LOG_ERR, "shmget msg failed %d", errno);
>  free_logarea();
>  return 1;
> @@ -114,7 +114,7 @@ static int logarea_init (int size)
>  la->tail = la->start;
> 
>  if ((shmid = shmget(IPC_PRIVATE, MAX_MSG_SIZE + sizeof(struct 
> logmsg),
> -   0644 | IPC_CREAT | IPC_EXCL)) == -1) {
> +   0600 | IPC_CREAT | IPC_EXCL)) == -1) {
>  syslog(LOG_ERR, "shmget logmsg failed %d", errno);
>  free_logarea();
>  return 1;
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/d6a22a2f-3730-45ee-5256-8a8fe4b0 
> 17bf%40huawei.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5E9D90BD02A100038651%40gwsmtp.uni-regensburg.de.

Antw: [EXT] replacement_timeout Override

[Ulrich Windl]

>>> Marc Smith  schrieb am 14.03.2020 um 15:28 in Nachricht
<29983_1584196109_5E6CEA0D_29983_1691_1_CAH6h+hdZ7QvF_WuLU5PJVpe4RpjM4EeEW7aBQVZ
forzv1p...@mail.gmail.com>:
> Hi,
> 
> I'm using open-iscsi version 2.1.1. I noticed that my
> "replacement_timeout" value set in the node record is not being
> applied, or rather is not overriding the default value set in
> iscsid.conf:
> 
> # iscsiadm -m node -T internal_redirect | grep replacement_timeout
> node.session.timeo.replacement_timeout = 5
> 
> # cat /etc/iscsi/iscsid.conf | grep replacement_timeout
> node.session.timeo.replacement_timeout = 120
> 
> # cat /sys/class/iscsi_session/session1/recovery_tmo
> 120
> 
> # iscsiadm -m session -P 2 | grep Recovery
> Recovery Timeout: 120
> 
> I can certainly change this value in iscsid.conf, but I was thinking
> my value in the node record would override this (for this specific
> target). Is it expected that this value should override what's in
> iscsid.conf? If so, then I assume I've hit a bug, or perhaps I have
> something configured incorrectly?
> 
> Thanks for your time.

I think whatever it was designed to do, there should be a "notice" at least 
that some specified setting is ignored if it is.

> 
> --Marc
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/CAH6h%2BhdZ7QvF_WuLU5PJVpe4RpjM4 
> EeEW7aBQVZrfOrZV1PLCA%40mail.gmail.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5E6F2B5402A100037C8B%40gwsmtp.uni-regensburg.de.

Antw: [EXT] [PATCH] scsi: Replace zero-length array with flexible-array member

[Ulrich Windl]

Hi!

Personally I think variable-sized structures are a bad thing, independent of 
the syntax being used.
30 years ago saving one indirection would have been an argument for such 
structures, but nowadays?

Regards,
Ulrich

>>> "Gustavo A. R. Silva"  schrieb am 24.02.2020 um 
>>> 17:14
in Nachricht
<32123_1582744382_5E56C33B_32123_188_1_20200224161406.GA21454@embeddedor>:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
> 
> struct foo {
> int stuff;
> struct boo array[];
> };
> 
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
> 
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
> 
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
> 
> This issue was found with the help of Coccinelle.
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html 
> [2] https://github.com/KSPP/linux/issues/21 
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/scsi/fnic/vnic_devcmd.h  |  2 +-
>  drivers/scsi/ipr.h   |  6 +++---
>  drivers/scsi/isci/sas.h  |  2 +-
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  2 +-
>  drivers/scsi/mvsas/mv_sas.h  |  2 +-
>  drivers/scsi/mvumi.h |  4 ++--
>  drivers/scsi/pmcraid.h   |  2 +-
>  drivers/scsi/snic/vnic_devcmd.h  |  2 +-
>  drivers/scsi/stex.c  |  2 +-
>  include/scsi/iscsi_if.h  | 10 +-
>  include/scsi/scsi_bsg_iscsi.h|  2 +-
>  include/scsi/scsi_device.h   |  4 ++--
>  include/scsi/scsi_host.h |  2 +-
>  include/scsi/scsi_ioctl.h|  2 +-
>  include/scsi/srp.h   |  8 
>  include/uapi/scsi/scsi_bsg_fc.h  |  2 +-
>  16 files changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/scsi/fnic/vnic_devcmd.h 
> b/drivers/scsi/fnic/vnic_devcmd.h
> index c5dde556dc7c..c20d30e36dfc 100644
> --- a/drivers/scsi/fnic/vnic_devcmd.h
> +++ b/drivers/scsi/fnic/vnic_devcmd.h
> @@ -442,7 +442,7 @@ struct vnic_devcmd_notify {
>  struct vnic_devcmd_provinfo {
>   u8 oui[3];
>   u8 type;
> - u8 data[0];
> + u8 data[];
>  };
>  
>  /*
> diff --git a/drivers/scsi/ipr.h b/drivers/scsi/ipr.h
> index a67baeb36d1f..fd3929a19ab5 100644
> --- a/drivers/scsi/ipr.h
> +++ b/drivers/scsi/ipr.h
> @@ -451,12 +451,12 @@ struct ipr_config_table_hdr64 {
>  
>  struct ipr_config_table {
>   struct ipr_config_table_hdr hdr;
> - struct ipr_config_table_entry dev[0];
> + struct ipr_config_table_entry dev[];
>  }__attribute__((packed, aligned (4)));
>  
>  struct ipr_config_table64 {
>   struct ipr_config_table_hdr64 hdr64;
> - struct ipr_config_table_entry64 dev[0];
> + struct ipr_config_table_entry64 dev[];
>  }__attribute__((packed, aligned (8)));
>  
>  struct ipr_config_table_entry_wrapper {
> @@ -792,7 +792,7 @@ struct ipr_mode_page28 {
>   struct ipr_mode_page_hdr hdr;
>   u8 num_entries;
>   u8 entry_length;
> - struct ipr_dev_bus_entry bus[0];
> + struct ipr_dev_bus_entry bus[];
>  }__attribute__((packed));
>  
>  struct ipr_mode_page24 {
> diff --git a/drivers/scsi/isci/sas.h b/drivers/scsi/isci/sas.h
> index dc26b4aea99e..15d8f3631ab7 100644
> --- a/drivers/scsi/isci/sas.h
> +++ b/drivers/scsi/isci/sas.h
> @@ -201,7 +201,7 @@ struct smp_req {
>   u8 func;/* byte 1 */
>   u8 alloc_resp_len;  /* byte 2 */
>   u8 req_len; /* byte 3 */
> - u8 req_data[0];
> + u8 req_data[];
>  }  __packed;
>  
>  /*
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index c597d544eb39..778d5e6ce385 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -207,7 +207,7 @@ struct fw_event_work {
>   u8  ignore;
>   u16 event;
>   struct kref refcount;
> - charevent_data[0] __aligned(4);
> + charevent_data[] __aligned(4);
>  };
>  
>  static void fw_event_work_free(struct kref *r)
> diff --git a/drivers/scsi/mvsas/mv_sas.h b/drivers/scsi/mvsas/mv_sas.h
> index 519edc796691..327fdd5ee962 100644
> --- a/drivers/scsi/mvsas/mv_sas.h
> +++ b/drivers/scsi/mvsas/mv_sas.h
> @@ -394,7 +394,7 @@ struct mvs_info {
>   dma_addr_t bulk_buffer_dma1;
>  #define TRASH_BUCKET_SIZE

Antw: reboot hangs with "Reached target shutdown", who can help me?

[Ulrich Windl]

Hi!

I think the problem is more related to systemd, rather than iscsi.
Personally I hate systemd, but you don't wnat to know that...

Regards,
Ulrich

>>> can zhu  schrieb am 10.12.2019 um 15:25 in Nachricht
<372db1a3-424d-4063-bcdb-ccb0b821d...@googlegroups.com>:
> os version:
> 
> CentOS Linux release 7.4.1708 (Core)
> 
> kernel version:  
> 
> 3.10.0-693.el7.x86_64
> 
> 
> systemd version:
> 
> *systemd*-219-42.el7.x86_64
> 
> 
> Mount iscsi devices on the node(iscsi client node) and reboot os, hangs:
> 
> [image: WechatIMG2178.png]
> 
> 
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/372db1a3-424d-4063-bcdb-ccb0b821 
> df0b%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5DEFAC4902A10003598D%40gwsmtp.uni-regensburg.de.

Antw: [PATCH V4] scsi: avoid potential deadlock in iscsi_if_rx func

[Ulrich Windl]

>>> "wubo (T)"  schrieb am 20.11.2019 um 14:26 in Nachricht
:
> In iscsi_if_rx func, after receiving one request through iscsi_if_recv_msg 
> func,
> iscsi_if_send_reply will be called to try to reply the request in do-loop. 
> If the return of iscsi_if_send_reply func return -EAGAIN all the time, one 
> deadlock will occur.

I think the correct phrase is "livelock" as the CPU is busy in a loop (as 
opposed to waiting for an event that cannot arrive ever)
[...]


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5DD5460002A10003548B%40gwsmtp.uni-regensburg.de.

Antw: [PATCH AUTOSEL 4.19 054/237] scsi: iscsi_tcp: Explicitly cast param in iscsi_sw_tcp_host_get_param

[Ulrich Windl]

>>> Sasha Levin  schrieb am 16.11.2019 um 16:38 in Nachricht
<20191116154113.7417-54-sas...@kernel.org>:
> From: Nathan Chancellor 
> 
> [ Upstream commit 20054597f169090109fc3f0dfa1a48583f4178a4 ]
> 
> Clang warns when one enumerated type is implicitly converted to another.

IMHO even an explicit cast doesn't make it better: Either it's the same enum, 
or it's a different one.
The only clean solution IMHO would be a converter function like

enum out convert_enum_in(enum in i)
{
  switch (i)
  {
 case enum_in_1: return enum_out_1; break;
 case enum_in_2: return enum_out_2; break;
 ...
 default: bad_value(i);
  }
}

Maybe a clever compiler can make this (almost) a no-op, but it should be clear 
that assigning different enums to each other is a bad idea.

> 
> drivers/scsi/iscsi_tcp.c:803:15: warning: implicit conversion from
> enumeration type 'enum iscsi_host_param' to different enumeration type
> 'enum iscsi_param' [-Wenum-conversion]
>  , param, buf);
> ^
> 1 warning generated.
> 
> iscsi_conn_get_addr_param handles ISCSI_HOST_PARAM_IPADDRESS just fine
> so add an explicit cast to iscsi_param to make it clear to Clang that
> this is expected behavior.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/153 
> Signed-off-by: Nathan Chancellor 
> Reviewed-by: Nick Desaulniers 
> Signed-off-by: Martin K. Petersen 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/scsi/iscsi_tcp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index b025a0b743417..23354f206533b 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -800,7 +800,8 @@ static int iscsi_sw_tcp_host_get_param(struct Scsi_Host 
> *shost,
>   return rc;
>  
>   return iscsi_conn_get_addr_param((struct sockaddr_storage *)
> -  , param, buf);
> +  ,
> +  (enum iscsi_param)param, buf);
>   default:
>   return iscsi_host_get_param(shost, param, buf);
>   }
> -- 
> 2.20.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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/20191116154113.7417-54-sashal%40 
> kernel.org.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5DD2642F02A1000353FC%40gwsmtp.uni-regensburg.de.

Antw: Re: iSCSI packet generator

[Ulrich Windl]

Hi!

Just a note of curiosity: Several years ago I wanted to test some RAID 
configurations, but had no server with enough disks. However the server had a 
lot of RAM (by that time). So I ended with creating a few small ramdisks which 
I exported as iSCSI devices. The host was happy with those "disks".
In the meantime the devicemapper can even inject "I/O errors", so maybe you can 
build a useful scenario for some basic tests. Like this:
---
DEV=bad_disk
dmsetup create "$DEV" <>> Bobby  schrieb am 06.11.2019 um 22:49 in 
>>> Nachricht
<0c2592cf-ad61-4fe4-8006-63edabe4a...@googlegroups.com>:

> Hi Donald,
> Hi The Lee-man,
> 
> Thanks for the reply. Both replies were helpful and both replies actually 
> clarified my concepts. And I realized, the question was not clearYou 
> were kind enough to reply in detail even when the question of was not clear 
> !
> 
> *The Lee-man*, your guess was right. I was thinking something like that and 
> I realized it makes no sense.
> 
> *Donald*: Yes, you are right. I took this point of yous "*then doing normal 
> I/O to that iSCSI disk will provide all the traffic you will typically 
> need*"the 
> wireshark showed me ! 
> 
> I'm a novice in Open-iSCSI yet very much interested in it. Please excuse my 
> simple questions. It is written, Open-iSCSI acts as "*kernel driver*" 
> between "*block layer*" and "*network layer*". Therefore following two 
> questions:
> 
> - Linux block layer perform IO scheduling IO submissions to storage device 
> driver. If there is a physical device, the block layer interacts with it 
> through SCSI mid layer and SCSI low level drivers. So, how *actually* a 
> software initiator (*Open-iSCSI*) interacts with "*block layer*"?  I will 
> be really grateful if you can explain me. 
> 
> - What confuses me, where does the "*disk driver*" comes into play?
> 
> Thanks :-)
> 
> 
> On Monday, November 4, 2019 at 5:43:24 PM UTC+1, The Lee-Man wrote:
>>
>> On Monday, November 4, 2019 at 2:49:08 AM UTC-8, Bobby wrote:
>>>
>>> Hi
>>>
>>> I have two virtual machines. One is a client and other is a sever (SAN). 
>>> I am using Wireshark to  analyze the iSCSI protocols between them.
>>>
>>> Someone recommended me, in addition to a packet analyzer, I can also use 
>>> a packet generator. Any good packet generator for iSCSI client/server model?
>>>
>>> Thanks
>>>
>>
>> Your question is not clear, but I'm *guessing*  you are asking if you can 
>> use some sort of software to inject iSCSI packets into your client/server 
>> stream, e.g. so that you can simulate errors and see how your software 
>> handles them?
>>
>> If so, then the answer is no, there is nothing I know of.
>>
>> Such "bad command injection" can be done with fancy hardware analyzers. A 
>> good (expensive) network analyzer can (I believe) inject bad packets of any 
>> type.See https://www.firewalltechnical.com/packet-injection-tools/ 
>>
>> It sound like none of this is directly related to open-iscsi, though.
>>
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/0c2592cf-ad61-4fe4-8006-63edabe4 
> af7f%40googlegroups.com.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5DC3F33402A100034E56%40gwsmtp.uni-regensburg.de.

Antw: [PATCH v2] scsi: avoid potential deadloop in iscsi_if_rx func

[Ulrich Windl]

>>> "wubo (T)"  schrieb am 30.10.2019 um 08:56 in Nachricht
:
> From: Bo Wu 

...
> + if (--retries < 0) {
> + printk(KERN_ERR "Send reply failed too many 
> times. "
> +"Max supported retries %u\n", 
> ISCSI_SEND_MAX_ALLOWED);

Just for "personal taste": Why not simplify the message to:?
+   printk(KERN_ERR "Send reply failed too many 
times (%u)\n",
   ISCSI_SEND_MAX_ALLOWED);

> + break;
> + }
> +

Maybe place the number after "many" as an alternative. I think as the message 
is expected to be rare, a short variant is justified.
Also one could discuss wether the problem that originates "from external" 
should be KERN_ERR, or maybe just a warning, because the kernel itself can do 
little against that problem, and it's not a "kernel error" after all ;-)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5DB946E102A100034B9C%40gwsmtp.uni-regensburg.de.

Antw: Re: CEPH ISCSI Gateway - very slow performance - Fine tuning help

[Ulrich Windl]

>>> "Ulrich Windl"  schrieb am 14.02.2019 um
09:05 in Nachricht <5c65213302a10002f...@gwsmtp1.uni-regensburg.de>:
> filesystems like ext3 occasionally make bug requests (like 1000 sectors), and 

Sorry: s/bug/big/


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

Antw: Re: CEPH ISCSI Gateway - very slow performance - Fine tuning help

[Ulrich Windl]

>>> ASVINCHANDAR SELVARAJ  schrieb am 14.02.2019 um 
>>> 06:03
in Nachricht
:
> I tried this
> 
> Centos 7.4
> 
> echo '4096000' > /sys/block/sdb/queue/max_sectors_kb
> 
> But I am getting Input/output error

Actually for FC SAN storage we made the opposite experience: Some filesystems 
like ext3 occasionally make bug requests (like 1000 sectors), and such big 
requests slow down the SAN storage. We use values significantly below 128kB.

I'd recommend to do analysis before doing tuning, or do an automated tuning 
test to find out which values give the best performance in your scenario. You 
could also use tools like iftop or iotop to monitor local and remote I/O.

Regards,
Ulrich

> 
> 
> On Wed, Feb 13, 2019 at 7:29 PM Chan  wrote:
> 
>> Hello
>>
>> I am having few severe performance issues on my ceph cluster.
>>
>>
>> Scenario 1 )When I mount a rbd volume directly using rbd map command
>> to a linux kernel. I am getting good performance.
>> when I do dd on the above volume, I am getting 380 - 430 MB's. -- I am
>> good with this.
>>
>>
>> Scenario 2 ) I am using iscsi-gateway. iscsi1 and iscs2 as targets and
>> presenting LUNS ro all my initiators.
>>
>>
>> When I do dd on the volumes presented via iscsi gateway, my performance is
>> 10 to 25 MB's. which is very poor.
>>
>> I am gwcli commandline and connot use the belwo command
>>
>> "create images image=test1 size=100g max_data_area_mb=128"
>>
>> ' Unexpected keyword error '
>>
>> --
>> 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.

Antw: Re: Initial Login Advice

[Ulrich Windl]

Hi!

I wonder: On Fibre-Channel (FC) SAN stroage systems, some systems indicate when 
there are new LUNs available, while others do not. Linux clients sometimes 
understand what the storage system is telling them, sometimes not. So usually 
one has to rescan the scsi bus to find new (or obsolete) LUNs.
Does the SCSI protocol have provisions to indicate a new target is available? 
Maybe it depends on the details: I'd guess a device that is in the state of 
becoming ready would be detected, but would have a state like "target is 
becoming ready" (which could be polled using TUR, I guess).
If the whole storage system is down, the situation is different, but in the FC 
case a new target would be still signalled on the FC bus at least (via LIP 
(loop Initialization Primitive) I think)...

Could such events trigger an iSCSI login?

Regards,
Ulrich

>>> The Lee-Man  schrieb am 04.11.2018 um 18:49 in
Nachricht :
> On Thursday, November 1, 2018 at 11:54:31 AM UTC-7, marc.sm...@parodyne.com 
> wrote:
>>
>> Hi,
>>
>> We use open-iscsi in our "ESOS" project. We have a custom rc/init script 
>> (not RHEL / Debian based), which starts the iSCSI initiator stack at boot. 
>> The current start() function in that script looks like this:
>> --snip--
>> start() {
>> if [ ! -f "${INAME_FILE}" ]; then
>> /bin/echo "Generating unique iSCSI initiator name..."
>> /bin/echo "InitiatorName=`${ISCSI_INAME}`" > ${INAME_FILE} || exit 
>> 1
>> fi
>> /bin/echo "Starting iSCSI initiator service..."
>> eval ${ISCSID} ${USER_OPTS} || exit 1
>> /bin/touch ${ISCSID_LOCK}
>> /bin/echo "Setting up iSCSI targets..."
>> ${ISCSIADM} -m node --loginall=automatic || exit 1
>> }
>> --snip--
>>
>> This all works just fine, but there is one behavior / scenario that 
>> occurs, and I'm looking for advice / best practices on how to overcome this:
>> - Let's say the remote iSCSI target server is down/unavailable
>> - An initiator (client) machine boots up, and the init script runs start() 
>> and the very last line of the function above (--loginall=automatic) 
>> attempts to login to all node/session records
>> - That command eventually times out of course if the iSCSI target that 
>> it's attempting to login to isn't up
>> - The storage target comes up sometime later, after the "iscsiadm 
>> --loginall=automatic ..." has already failed/returned
>> - The client/initiator machine then never logs in to the target without 
>> intervention (eg, running login by hand)
>>
>> I'd like to address this so there is no manual intervention needed, or at 
>> least not after some "reasonable" amount of time (eg, 12 hours, or 
>> whatever). My first thought is to tweak the initial login timeout values in 
>> iscsid.conf, and then background the "iscsiadm --loginall=automatic ..." 
>> that runs in the start() function of our rc/init script. But I'm wondering 
>> if there is a better, perhaps cleaner way, of achieving this behavior. I 
>> see some options related to "discoveryd" and retry attempts, but I'm not 
>> convinced that applies to my situation after reading some documentation / 
>> examples of that. The portal / target are all static on the initiator side, 
>> so I don't need to discover new targets each time, just login to existing 
>> target/portal/node records.
>>
>> Any help or guidance would be greatly appreciated. Thanks for your time.
>>
>> --Marc
>>
>>
> Hi Marc:
> 
> Good question. Others have asked this, and there is no good answer. There 
> is nothing I know of (built into open-iscsi) that will do as you wish, i.e. 
> "try to login to a node now, and if the node is not currently present, keep 
> trying again (forever, or for some amount of time) until it works.
> 
> But ... if you successfully have a session, and then the iscsid daemon goes 
> away and comes back and finds evidence of these now-stale sessions, it will 
> in fact retry forever to reconnect to them. Which is kind of what you want, 
> if I understand correctly.
> 
> There _are_ some approaches to working around this, I believe. We could do 
> one of:
> 
>- use iSNS, if you target supports it. The iSNS daemon is like a name 
>service for targets and initiators, and can send asynchronous messages to 
> a 
>client when a target goes down or comes up. This is probably the best 
> long 
>term solution, but needs some testing as proof-of-concept, as iSNS isn't 
>used much right now
>- Or we could use the discovery daemon, which isn't really a daemon but 
>a fork of the iscsid daemon that re-runs discovery for you, periodically. 
> I 
>_believe_ it can be set up to log into nodes it finds though, and also 
>needs some more testing.
>- Or you can create some custom, out-of-band test for (1) if the target 
>is up, try to login, else (2) sleep a while and try again, until (3) we 
>connect or give up after a certain time or number of tries
>- Or we can enhance iscsid to have this capability, since it's 

Antw: Re: max_sectors_kb so small, throughout so small

[Ulrich Windl]

Hi!

I'm somewhat surprised: Maybe it's all about latency, because with FC-SAN we
typically see a performance _decrease_ if large sequential requests are being
transmitted. So actually we did limit the default amount of max_sectors_kb.
Most "intelligent" SAN systems break down large requests to small internal
requests (like 128kB) that are being handled, and the initiator gets an
acknowledge once all such requests internal have finised.

Regards,
Ulrich

>>> Mike Christie  schrieb am 11.09.2018 um 18:30 in
Nachricht
<5b97edaf.80...@redhat.com>:
> Hey,
> 
> Cc mchri...@redhat.com, or I will not see these messages until I check
> the list maybe once a week.
> 
> On 09/05/2018 10:36 PM, 3kboy2...@gmail.com wrote:
>> What lio fabric driver are you using? iSCSI? What kernel version
>> and
>> what version of tcmu-runner?
>> 
>> io fabric driver :iscsi
>> 
>> iscsid version:  2.0-873
>> 
>> OS version:  CentOS Linux release 7.5.1804 (Core)
>> 
>> kernel version:  3.10.0-862.el7.x86_64 
>> 
>> tcmu-runner version:1.4.0-rc1
>> 
>> 
>> Target Build:
>> 
>> targetcli /iscsi create iqn.2018-09.com.test:target1
>> 
>> targetcli  /backstores/user:rbd create name=my_replicated_test
>> size=1000G cfgstring=rbd_pool/replicated_image1 hw_max_sectors=8192
> 
> That kernel has a default data area (kernel buffer used to pass scsi
> command data) of 8MB, so with a command size of 8192 sectors you could
> only 2 commands at once.
> 
> When you create the backstore pass it a new max_data_area_mb value like
> this (make sure you have the newest rtslib-fb, configshell-fb and
> targetcli-fb from the upstream github repos):
> 
> targetcli  /backstores/user:rbd create name=my_replicated_test
> size=1000G cfgstring=rbd_pool/replicated_image1 hw_max_sectors=8192
> control=max_data_area_mb=32
> 
> This would increase the buffer to 32 MB.
> 
> Or for an existing setup add the control line in the saveconfig.json
> between the config and hw_max_sectors line like this:
> 
>   "config": "rbd/rbd_pool/replicated_image"
>   "control": "max_data_area_mb=32",
>   "hw_max_sectors": 8192,
> 
> Note that this will prealloocate 32 MBs of memory for the device.
> 
>> 
>> targetcli  /iscsi/iqn.2018-09.com.test:target1/tpg1/luns create
>> /backstores/user:rbd/my_replicated_test
>> 
>> targetcli /iscsi/iqn.2018-09.com.test:target1/tpg1/portals create
>> 10.0.1.111
>> 
>> targetcli /iscsi/iqn.2018-09.com.test:target1/tpg1 set auth
>> userid=** password=**
>> 
>> targetcli /iscsi/iqn.2018-09.com.test:target1/tpg1 set attribute
>> authentication=1 demo_mode_write_protect=0 generate_node_acls=1 
>> 
>> 
>> Target Setting:
>> 
>>  
>> 
>> 屏幕快照 2018-09-06 上午10.43.11.png
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>> 
>> > Could you give me some suggestions about improving the
>> performance of
>> >  /backstore/user:rbd/ device.
>> >
>> > Thanks very much!
>> >
>> > 在 2018年9月3日星期一 UTC+8上午10:31:48，3kbo...@gmail.com写道：
>> >
>> > Hello Mike,
>> >
>> > Thank you for your informative response.
>> >
>> >
>> > 在 2018年8月28日星期二 UTC+8上午8:49:46，Mike Christie写道：
>> >
>> > On 08/21/2018 08:52 PM, 3kbo...@gmail.com wrote:
>> > > Hi folks,
>> > >
>> > > I am newbie to open-iscsi.
>> > > My case is I export ceph rbd by open-iscsi.
>> > >
>> > > I found the max_sectors_kb is 64, the value is so
>> small, and
>> > 4M sequence
>> > > write is only about 10MB/s.
>> > > I can not increase max_sectors_kb, if I do it will
>> return
>> > "bash: echo:
>> > > write error: Invalid argument"(But I can change the
>> value to a
>> > small one
>> > > < 64, max_hw_sectors_kb is 32767)
>> > >
>> >
>> > In new version of the linux kernel the initiator will
>> use the
>> > optimal
>> > value reported by the target and then uses the max
>> reported as
>> > the limit
>> > that the user can set. It sounds like you are using
>> rbd/ceph with
>> > tcmu-runner which has a default limits of 64K.
>> >
>> > Yes, I am using  tcmu-runner and gwcli.
>> >
>> >
>> > If you are using targetcli/lio directly then you can set
>> > hw_max_sectors
>> > through targcli when you create the device or in the
>> > saveconfig.json file.
>> >
>> > If you are using the ceph-iscsi tools then I am
>>

Antw: [PATCH 3/4] libopeniscsiusr: clear errno before calling strtoll

[Ulrich Windl]

>>> Chris Leech  schrieb am 13.06.2018 um 17:25 in Nachricht
<20180613152545.1049967-4-cle...@redhat.com>:
> errno must be set to 0 before calling strtoll or error checking will
> have false positives
> ---
>  libopeniscsiusr/sysfs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libopeniscsiusr/sysfs.c b/libopeniscsiusr/sysfs.c
> index 6f295b702821..d312d4e299d0 100644
> --- a/libopeniscsiusr/sysfs.c
> +++ b/libopeniscsiusr/sysfs.c
> @@ -229,6 +229,7 @@ static int iscsi_sysfs_prop_get_ll(struct iscsi_context 
> *ctx,
>   }
>   }
>  
> + errno = 0;
>   tmp_val = strtoll((const char *) buff, NULL, 10 /* base */);
>   errno_save = errno;
>   if ((errno_save != 0) && (! ignore_error)) {

Hi!

Relying on errno being set seems unreliable; a more reliable approach would use 
the return pointer (endptr) to check that there is no unprocessed rest. Thus 
the error condition would look like "if ( rest != NULL && rest[0] != '\0' )"...

Regards,
Ulrich

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




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

Antw: [PATCH 4/4] libopeniscsiusr: setup ipv6 records based on iface name

[Ulrich Windl]

>>> Chris Leech  schrieb am 13.06.2018 um 17:25 in Nachricht
<20180613152545.1049967-5-cle...@redhat.com>:
> The is_ipv6 flag (runtime iface rec representation only, not on disk)
> was being set when creating ifaces from sysfs, but not when reading them
> in from an iface record file. This caused ipv6 iface records to be
> reported as malformed and ignored.
> 
> Fix that with a name check for an "ipv6" substring. Old code also looked
> at other fields, this is enough to fix iface records created from sysfs
> for be2iscsi and qla4xxx. Further fixes might be required for other IPv6
> configurations.
> ---
>  libopeniscsiusr/idbm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libopeniscsiusr/idbm.c b/libopeniscsiusr/idbm.c
> index f7dc5923bb74..44f8a54caee2 100644
> --- a/libopeniscsiusr/idbm.c
> +++ b/libopeniscsiusr/idbm.c
> @@ -841,6 +841,9 @@ int _idbm_iface_get(struct iscsi_context *ctx, const 
> char *iface_name, struct
>   snprintf((*iface)->name, sizeof((*iface)->name)/sizeof(char),
>"%s", iface_name);
>  
> + if (strstr(iface_name, "ipv6"))
> + (*iface)->is_ipv6 = true;
> +

Hi!

As a matter of style, I would use some symbolic constant instead of "ipv6" when 
that string is some "magic constant" (Of course, not just here, but everywhere).

Regards,
Ulrich

>   recs = _idbm_recs_alloc();
>   _alloc_null_check(ctx, recs, rc, out);
>  
> -- 
> 2.14.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.




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

Antw: Re: [PATCH] Reduce delays to improve iscsi boot performance

[Ulrich Windl]

>>> The Lee-Man  schrieb am 16.04.2018 um 23:57 in
Nachricht <59dd48da-66d2-44c0-a2ef-669e1897f...@googlegroups.com>:
> On Monday, April 16, 2018 at 2:38:01 PM UTC-7, The Lee-Man wrote:
>>
>> On Friday, April 13, 2018 at 3:19:11 PM UTC-7, cathy.z...@oracle.com 
>> wrote:
>>>
>>> From: Cathy Zhou  
>>>
>>> iscsi boot performance can be improved by sleep() with finer 
>>> grained interval and exponential backoff. 
>>>
>>> Signed-off-by: Cathy Zhou  
>>> --- 
>>>  usr/iscsistart.c | 35 --- 
>>>  1 file changed, 24 insertions(+), 11 deletions(-) 
>>>
>>> diff --git a/usr/iscsistart.c b/usr/iscsistart.c 
>>> index 67ac475..1e77e40 100644 
>>> --- a/usr/iscsistart.c 
>>> +++ b/usr/iscsistart.c 
>>> @@ -27,6 +27,7 @@ 
>>>  #include  
>>>  #include  
>>>  #include  
>>> +#include  
>>>  #include  
>>>  #include  
>>>  #include  
>>> @@ -224,7 +225,8 @@ static int login_session(struct node_rec *rec) 
>>>  { 
>>>  iscsiadm_req_t req; 
>>>  iscsiadm_rsp_t rsp; 
>>> -int rc, retries = 0; 
>>> +int rc, msec, err; 
>>> +struct timespec ts; 
>>>   
>>>  rc = apply_params(rec); 
>>>  if (rc) 
>>> @@ -237,18 +239,29 @@ static int login_session(struct node_rec *rec) 
>>>  req.command = MGMT_IPC_SESSION_LOGIN; 
>>>  memcpy(, rec, sizeof(*rec)); 
>>>   
>>> -retry: 
>>> -rc = iscsid_exec_req(, , 0, ISCSID_REQ_TIMEOUT); 
>>>  /* 
>>> - * handle race where iscsid proc is starting up while we are 
>>> - * trying to connect. 
>>> + * Need to handle race where iscsid proc is starting up while we 
>>> are 
>>> + * trying to connect. Retry with exponential backoff, start from 
>>> 50 ms. 
>>>   */ 
>>> -if (rc == ISCSI_ERR_ISCSID_NOTCONN && retries < 30) { 
>>> -retries++; 
>>> -sleep(1); 
>>> -goto retry; 
>>> -} else if (rc) 
>>> -iscsi_err_print_msg(rc); 
>>> +for (msec = 50; msec <= 15000; msec <<= 1) { 
>>>
>>
>> Why are you using 50 -> 15000? Isn't the sequence then going to be:
>>   -> 50
>>   -> 100
>>   -> 200
>>   -> 400
>>   -> 800
>>   -> 1600 (too large)
>>
>> So why not either go to 800 or to 1600?
>>
>>
> Doh! I am off by a factor of 10!
> 
>   -> 3200, 6400, 12800

I'm late in the discussion, but I'd vote for three things:
1) Make the limits configurable (first delay, maximum wait duration)
2) Change the algorithm not to specify the last delay being used, but the total 
amount of waiting
3) Log if waiting for some longer time

I had implemented something like that years ago in Perl. Maybe to make it 
clearer what I'm thinking of, here's a code snipplet:


$self->Log(0, 'D', $logger, "Waiting up to $limit seconds for condition")
if ($verbosity > 1 && !$result);
no integer;
for (my $wait = $min_wait; !$result && $limit > 0;
 $limit -= $wait, $wait *= 2) {
$wait = $limit
if ($wait > $limit);
$self->Log(1, 'D', $logger,
   "Waiting $wait (of $limit remaining) seconds")
if ($verbosity > 0 && !$result);
# sleep $wait seconds to allow condition to become true
select(undef, undef, undef, $wait);
$result = $condition_r->($self);
}
$self->Log(1, 'D', $logger, "$condition_txt with $limit seconds remaining")
if ($verbosity > 0 && $result);

[...]

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

Antw: Re: 4.14.16 kworker deathspin if logged out without deleting scsi devices

[Ulrich Windl]

>>> Maxim Ivanov  schrieb am 15.02.2018 um 23:41 in
Nachricht :
> Investigating it further, it looks like it is working fine if multipathd 
> didn't start at all (unit is masked). If it was started, then stopped, 
> logout hangs.  

Did you wait for multipathd to finish before logging out? Multipathd can take a 
while to terminate all the path checkers...

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

Antw: [PATCH 14/15] staging: greybus: make device_type const

[Ulrich Windl]

>>> Bhumika Goyal  schrieb am 19.08.2017 um 10:22 in 
>>> Nachricht
<1503130946-2854-15-git-send-email-bhumi...@gmail.com>:
> Make this const as it is only stored in the type field of a device
> structure, which is const.

Hi!

I just have a comment on the patch description: What "this" and "it" refers to 
would be only obvious when actually reading the patch. IMHO the patch 
description should summarize the patch, so on gets an idea without actually 
reading the patch.

Regards,
Ulrich

> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 
> ---



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

Antw: Re: [RFC PATCH 4/6] bsg: refactor ioctl to use regular BSG-command infrastructure for SG_IO

[Ulrich Windl]

>>> Johannes Thumshirn  schrieb am 10.08.2017 um 10:24 in
Nachricht <20170810082456.gi4...@linux-x5ow.site>:
> On Wed, Aug 09, 2017 at 04:11:18PM +0200, Benjamin Block wrote:
>> +return 0 == (bc->hdr.flags & BSG_FLAG_Q_AT_TAIL);
> 
> return !(bc->hdr.flags & BSG_FLAG_Q_AT_TAIL); and make the function return
> bool? I have to admit, this is the 1st time I have seen the above construct.

So you never programmed BASIC like "goto 100 + (A >50) * 10 + (C < 7) * 10"? ;-)

The second variant is maybe a bit more modern as is converts Boolean to Boolean 
(that doesn't exist in classic C, BTW), while the first variant compares an 
integer with a "boolean" (that doesn't exist), to make another "boolean". 
Usually compilers handle this rather identical (IMHO).

Ulrich

> 
> Thanks,
>   Johannes


-- 
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: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

[Ulrich Windl]

>>> Paul Koning <paulkon...@comcast.net> schrieb am 05.07.2017 um 15:16 in
Nachricht <8cc15605-cff3-4d6e-adbe-5efc9f8e7...@comcast.net>:

>> On Jul 5, 2017, at 3:08 AM, Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> 
> wrote:
>> 
>>>>> Jeffrey Walton <noloa...@gmail.com> schrieb am 17.06.2017 um 16:23 in 
> Nachricht
>> <cah8yc8nhx2r9cfq0gnejaurgsfas8v16dvhv35brnln-ypr...@mail.gmail.com>:
>> 
>> [...]
>>> But its not clear to me how to ensure uniqueness when its based on
>>> randomness from the generators.
>> 
>> Even with a perfect random generator non-unique values are possible (that's 
> why it's random). It's unlikely, but it can happen. The question is whether 
> the probability of non-unique values from /dev/urandom is any higher than 
> that for values read from /dev/random. One _might_ be able to predict the 
> values from /dev/urandom.
> 
> In the implementations I know, /dev/random and /dev/urandom are the same 
> driver, the only difference is that when you read from /dev/random there's a 
> check for the current entropy level.
> 
> If you haven't fed enough entropy yet to the driver since startup, and you 
> read /dev/urandom, you get a value that isn't sufficiently secure.  

Seeing it as a blackbox, you never know when additional entropy will be fed in, 
so you MIGHT get a value that isn't sufficiently secure. Only if you are sure 
no entropy is fed into the pool, you are likely to guess the next value. I 
think only if you have observed a lot of values to deduce the internal state of 
the pool, however.

> 
> If you have a properly constructed RNG, as soon as it's been fed enough 
> entropy it is secure (at least for the next 2^64 bits or so).  The notion of 
> "using up entropy" is not meaningful for a good generator.   See Bruce 
> Schneier's "Yarrow" paper for the details.

I don't know that paper (yet). But saying you only need a limited amount of 
"good entropy" and then a generator is secure surprises me from what I know so 
far.
An attacker knowing the algorithm is required to never detect the internal 
state of the generator (which is finite).

Regards,
Ulrich

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

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

[Ulrich Windl]

>>> Stephan Müller  schrieb am 26.06.2017 um 19:38 in
Nachricht <1678474.gnybdsl...@tauon.chronox.de>:
> Am Montag, 26. Juni 2017, 03:23:09 CEST schrieb Nicholas A. Bellinger:
> 
> Hi Nicholas,
> 
>> Hi Stephan, Lee & Jason,
>> 
>> (Adding target-devel CC')
>> 
>> Apologies for coming late to the discussion.  Comments below.
>> 
>> On Sun, 2017-06-18 at 10:04 +0200, Stephan Müller wrote:
>> > Am Samstag, 17. Juni 2017, 05:45:57 CEST schrieb Lee Duncan:
>> > 
>> > Hi Lee,
>> > 
>> > > In your testing, how long might a process have to wait? Are we talking
>> > > seconds? Longer? What about timeouts?
>> > 
>> > In current kernels (starting with 4.8) this timeout should clear within
a
>> > few seconds after boot.
>> > 
>> > In older kernels (pre 4.8), my KVM takes up to 90 seconds to reach that
>> > seeding point. I have heard that on IBM System Z this trigger point
>> > requires minutes to be reached.
>> 
>> I share the same concern as Lee wrt to introducing latency into the
>> existing iscsi-target login sequence.
>> 
>> Namely in the use-cases where a single node is supporting ~1K unique
>> iscsi-target IQNs, and fail-over + re-balancing of IQNs where 100s of
>> login attempts are expected to occur in parallel.
>> 
>> If environments exist that require non trivial amounts of time for RNG
>> seeding to be ready for iscsi-target usage, then enforcing this
>> requirement at iscsi login time can open up problems, especially when
>> iscsi host environments may be sensitive to login timeouts, I/O
>> timeouts, et al.
>> 
>> That said, I'd prefer to simply wait for RNG to be seeded at modprobe
>> iscsi_target_mod time, instead of trying to enforce randomness during
>> login.
>> 
>> This way, those of use who have distributed storage platforms can know
>> to avoid putting a node into a state to accept iscsi-target IQN export
>> migration, before modprobe iscsi_target_mod has successfully loaded and
>> RNG seeding has been confirmed.
>> 
>> WDYT..?
> 
> We may have a chicken and egg problem when the wait is at the modprobe time.

> 
> Assume the modprobe happens during initramfs time to get access to the root

> file system. In this case, you entire boot process will lock up for an 
> indefinite amount of time. The reason is that in order to obtain events 
> detected by the RNG, devices need to be initialized and working. Such 
> devices 
> commonly start working after the the root partition is mounted as it 
> contains 
> all drivers, all configuration information etc.
> 
> Note, during the development of my /dev/random implementation, I added the 
> getrandom-like blocking behavior to /dev/urandom (which is the equivalent to

> 
> Jason's patch except that it applies to user space). The boot process locked


I thought reads from urandom never block by definition. An older manual page
(man urandom) also says: "A  read  from  the  /dev/urandom device will not
block waiting for more entropy."

Regards,
Ulrich

> 
> up since systemd wanted data from /dev/urandom while it processed the 
> initramfs. As it did not get any, the boot process did not commence that 
> could 
> deliver new events to be picked up by the RNG.
> 
> As I do not have such an iscsi system, I cannot test Jason's patch. But 
> maybe 
> the mentioned chicken-and-egg problem I mentioned above is already visible 
> with the current patch as it will lead to a blocking of the mounting of the

> root partition in case the root partition is on an iscsi target.
> 
> Ciao
> Stephan
> 
> -- 
> 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.

Antw: Diskless iSCSI boot Configuration

[Ulrich Windl]

>>>  schrieb am 15.05.2017 um 20:40 in Nachricht
:
> Hello guys, 
> I am trying to configure a diskless PC to boot through an iSCSI server. 
> I have already configure the iSCSI Target side and the PC through a Live 
> USB is accessed to the iSCSI target. With fdisk -l command, I can see the 
> disk that I want to use. there is no any partion in the disk. 
> From this point I do not know what to do, because I have found many 
> different kind of tutorials and I do not understand some points. 
> 
> For example, can somebody explain me why after the regular installation of 
> the OS on the iSCSI disk they use the "mount" command for the /dev. /sys 
> and /proc? 
> 
> helper# mkdir /mnt/chroot 
> helper# mount /dev/sda3 /mnt/chroot 
> helper# debootstrap wheezy /mnt/chroot 
> helper# mount -t proc none /mnt/chroot/proc 
> helper# mount -t sysfs none /mnt/chroot/sys 
> helper# mount --bind /dev /mnt/chroot/dev 
> helper# chroot /mnt/chroot /bin/bash 
> 
> Does anyone know what these commands do ? 

Well what these comamnds can be read in the corresponding manual pages ;-)
But I guess your question was: Why are these needed?
Obviously you need all the fielesystems you want to access. /proc, /sys, and 
/dev are needed if you want to build your initial ramdisk (from my experience), 
because otherwise they are not present after chroot.

Regards,
Ulrich

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

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

[Ulrich Windl]

>>> Christian Seiler  schrieb am 26.04.2017 um 09:14 
>>> in
Nachricht :
> 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:

I'm no JSON fan either, but I think IPC is much lower level than dbus is (which 
is good during boot to keep initrd small). So dbus has to have benefits over a 
simpler mechanism tu justify it.

> 
>  - introspection support
>  - the object-based view it provides lends itself well to the
>problem at hand
>  - a _lot_ of tooling
>  - lots of language bindings
>  - support for notifications (signals): this allows iscsid to
>broadcast changes to anyone who's interested
>  - authorization can be managed entirely via PolicyKit, so
>there's no need t invent an own authentication and
>authentication system, one can leverage something that many
>people are already used to
> 
> There are some caveats though:
> 
>  - the DBus daemon might not have been started at the point
>where iscsid is started
> 
>  - the DBus daemon might be stopped before iscsid is suppoed
>to stop, so the DBus connection could go away at any time
> 
> However, I think both of these issues are solvable:
> 
>  1. If the DBus connection can't be established at startup,
> don't consider that to be a failure, just continue on.
> 
>  2. Upon receiving SIGUSR1 (or similar), try to reconnect to
> the system bus. iscsid could be sent SIGUSR1 from a
> service file / init script after DBus is up and running
> 
>  3. If the system bus connection goes away, don't fail, just
> continue on. Maybe try to reconnect immediately once, in
> case someone just restarted the daemon.
> 
> 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.




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

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

[Ulrich Windl]

>>>  schrieb am 27.03.2017 um 18:03 in Nachricht
:
> 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.

Hi!

I may be old-fashioned, but did you listen to the drive? Is it possible that 
the drives does to stop-and-go mode where it has to rewind to re-capture the 
last position periodically? I know that some drives can adjust their peeds to 
transport bandwidth, but some drives always operate at full speed, forcing them 
to stop and go.
Also: Did you try to write directly from dd to the tape (being able to control 
the block size)?

Regards,
Ulrich

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

Antw: Re: Problem with iSCSI connected LTO-2 tape drive

[Ulrich Windl]

>>> Lee Duncan  schrieb am 14.12.2016 um 20:18 in
Nachricht <8286a277-f7fe-4c7d-a944-40034a0b5...@gmail.com>:
> On Dec 12, 2016, at 5:46 AM, 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
> 
> Hi Dave:
> 
> I think you are right — the problem is the timeout.
> 
> The default timeout on many systems (like SUSE that I work on) is set to 60

> seconds for a SCSI command. And it looks like the tape drive took about 82 
> seconds to skip forward a file on your Windows trace.

AFAIK, 60s is the SCSI _disk_ timeout; for tapes the timeout should be
significantly longer (depending on the technology).

> 
> Try setting the timeout to 90 seconds? The open-iscsi README talks about how

> to manually set the system SCSI timeout to longer (since this isn’t an
iSCSI 
> thing).

15 minutes or so?

> 
> Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. 
> This is also discussed in the README file. I’d try setting them both to 0
to 
> get them out of the way. It looks like the tape drive does not respond to
the 
> NOOP ping when it is busy for 80+ seconds skipping forward one file.

Regards,
Ulrich


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



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

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

[Ulrich Windl]

>>>  schrieb am 22.11.2016 um 23:42 in Nachricht
:
[...]
> 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.

Good common practice see to perform an orderly (clean) shutdown on first 
receipt of SIGTERM; if another SIGTERM arrives a few seconds (time depending on 
the application) later, a more immediate shutdown should be attempted (still 
trying to be as clean as possible).

I had implemented such a pattern in a network server, and I'll use it for an 
example here (forgive!):
1st signal prevents accepting new connections; server will shut down if all 
connections are gone
2nd signal will shutdown connections if current requests have been answered
3rd signal will terminate active connections (those who transfer data) (i.e. 
after a recv/send)
4th signal will terminate connections blocked on sending or receiving data 
(i.e. kill an "active" recv/send)
So eventually the server will arrive in the "1st signal received state" 
eventually...

Regards,
Ulrich

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




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

Antw: Re: RFC: iscsid shutdown hangs with system when service manually killed

[Ulrich Windl]

>>> "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> schrieb am 22.11.2016 um
08:43 in Nachricht <5834052f02a100023...@gwsmtp1.uni-regensburg.de>:

[...]
> I also think that a look with three "continue" and one "break" is a bit

s/look/loop/ # user not fully awake ;-)



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

Antw: RFC: iscsid shutdown hangs with system when service manually killed

[Ulrich Windl]

If a human talks to a person that isn't there you call him/her crazy.
If software talks to a process that isn't there, you call it a bug (I guess) ;-)
To me the proper fix is to ensure iscsid is running before trying to talk to it 
(stop it)

Ulrich

>>> The Lee-Man  schrieb am 19.11.2016 um 20:46 in
Nachricht <8a073594-4c61-402b-825e-63f42420a...@googlegroups.com>:
> 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.




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

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

[Ulrich Windl]

>>>  schrieb am 10.11.2016 um 11:16 in Nachricht
<4e2f30b5-7c75-47d6-ad1e-2470b92bd...@googlegroups.com>:

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

Did you try "lsscsi -t"? Look at the source then.

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

Antw: Open-Iscsi working

[Ulrich Windl]

>>> Raghu Murugesan  schrieb am 09.11.2016 um 00:18 in
Nachricht <486524a5-8b14-4c0a-bf3f-b755b4561...@googlegroups.com>:
> I want to understand how open-iscsi implements the RFC3720. I read RFC3720 
> to understand how iscsi works. 
> 
> But I could understand how this RFC3720 is implemented in open-iscsi code. 
> There are a lot of files with few thousand line of code which making things 
> difficult to understand for someone new like me.
> 
> Can anyone give me some suggestion on how understand open-iscsi 
> implementation. Any links or resources to read?
> 
> I know this sounds dumb. But I really need this help since I am new to this 
> field.

I suggest to start from the other end: Instead of trying to understand what the 
implementation code does to fulfill the RFC, I'd try to start using it, trying 
to find out which command is used to do things described in the RFC. Then do 
deeper into it...

> 
> Thanks for reading this post. 
> 
> - Raghu
> 
> -- 
> 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.

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

[Ulrich Windl]

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

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

Antw: Re: Does iSCSI protocol have an integrated cache scheme?

[Ulrich Windl]

I guess your problem is similar to caching a local spinning disk using a local 
SSD, unrelated to iSCSI. I once readabout some solutions, but cannot remember. 
Maybe googling on "linux cache device" or "block device cache" could help you.

Regards,
Ulrich

>>> ??? <mxh714...@gmail.com> schrieb am 11.10.2016 um 04:36 in Nachricht
<campnguzu9bdmbtpuxtxaaqt7b8eo8uzot+23z5mewa6hwbh...@mail.gmail.com>:
> Hi Ulrich,
> you maybe misunderstood my purpose, i am not going to do caching on iSCSI
> transport layer.
> you are right that  iSCSI devices can be cached just as normal block
> devices are.
> indeed a normal block device can be cached using memory to cache the hot
> data.
> but iscsi driver has differences with normal block device, after all it's a
> remote disk.
> so i want to use a normal block device to act as a cache disk for iscsi
> device besides using the normal memory cache.
> do you have any suggestions?
> thank you!
> 
> 2016-10-10 21:43 GMT+08:00 Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de>:
> 
>> The iSCSI transport layer is definitely the wrong place to do caching!
>> iSCSI devices are cached just as normal block devices are (unless you use
>> direct I/O).
>>
>> >>> ??? <mxh714...@gmail.com> schrieb am 10.10.2016 um 11:46 in Nachricht
>> <b78a2a6a-5f86-4d75-9acd-1aa069a1e...@googlegroups.com>:
>>
>> >
>> > does iSCSI protocol itself or open-source iSCSI implementations like
>> > open-iscsi have a cache scheme?
>> >
>> > since an iscsi initiator may access the same data many times, it does not
>> > have to get the data from remote target every time via network. so i am
>> > wondering if iSCSI provides a scheme by which clients can use a local
>> disk
>> > to cache the hot data so that when the accessed data is stored in the
>> local
>> > cache disk initiator can directly get the data from local disk, just
>> like a
>> > web browser cache does. does anyone konw about this?
>> >
>> > how can i implement this? thank you.
>> >
>> >
>> > --
>> > 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 a topic in the
>> Google Groups "open-iscsi" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/ 
>> topic/open-iscsi/uVZSZV1pz1M/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.




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

Antw: Does iSCSI protocol have an integrated cache scheme?

[Ulrich Windl]

The iSCSI transport layer is definitely the wrong place to do caching! iSCSI 
devices are cached just as normal block devices are (unless you use direct I/O).

>>> ???  schrieb am 10.10.2016 um 11:46 in Nachricht
:

> 
> does iSCSI protocol itself or open-source iSCSI implementations like 
> open-iscsi have a cache scheme?
> 
> since an iscsi initiator may access the same data many times, it does not 
> have to get the data from remote target every time via network. so i am 
> wondering if iSCSI provides a scheme by which clients can use a local disk 
> to cache the hot data so that when the accessed data is stored in the local 
> cache disk initiator can directly get the data from local disk, just like a 
> web browser cache does. does anyone konw about this?
> 
> how can i implement this? thank you. 
> 
> 
> -- 
> 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.

Antw: Re: [PATCH] iscsi_ibft,iscsi_boot: remove CAP_SYS_ADMIN restriction for reading entries

[Ulrich Windl]

>>> Konrad Rzeszutek Wilk  schrieb am 05.10.2016 um 01:23 in
Nachricht
:
> On Oct 4, 2016 12:11 PM, "Dan Williams"  wrote:
>>
>> On Tue, 2016-10-04 at 12:08 -0400, Peter Jones wrote:
>> > On Tue, Oct 04, 2016 at 11:03:05AM -0500, Dan Williams wrote:
>> > >
>> > > All the iSCSI boot entries are read-only anyway; it's unclear why
>> > > the
>> > > CAP_SYS_ADMIN restriction is in place since this information isn't
>> > > particularly sensitive and cannot be changed.  Userspace
>> > > applications
>> > > may want to read this without requiring CAP_SYS_ADMIN for their
>> > > entire process just for iBFT info.
>> > >
>> > > Signed-off-by: Dan Williams 
>> >
>> > Uh, because there are login credentials to the target in there.
>>
>> Fair enough.  So can we just check CAP_SYS_ADMIN for the login
>> credentials, and not check it for all the IP details and such?
> 
> The only consumer is iscsiadm - which runs as root. So why expose this
> information to non root ?

Probaby the correct question is: Can iscsiadm also run as non-root?
The tendency in UNIX (linux) security is to do administrative tasks as non-root 
when possible. Mostly because root is too powerful.

> 
>>
>> Dan
>>
>> > >
>> > > ---
>> > >  drivers/scsi/iscsi_boot_sysfs.c | 3 ---
>> > >  1 file changed, 3 deletions(-)
>> > >
>> > > diff --git a/drivers/scsi/iscsi_boot_sysfs.c
>> > > b/drivers/scsi/iscsi_boot_sysfs.c
>> > > index d453667..4e9c324 100644
>> > > --- a/drivers/scsi/iscsi_boot_sysfs.c
>> > > +++ b/drivers/scsi/iscsi_boot_sysfs.c
>> > > @@ -47,9 +47,6 @@ static ssize_t iscsi_boot_show_attribute(struct
>> > > kobject *kobj,
>> > > ssize_t ret = -EIO;
>> > > char *str = buf;
>> > >
>> > > -   if (!capable(CAP_SYS_ADMIN))
>> > > -   return -EACCES;
>> > > -
>> > > if (boot_kobj->show)
>> > > ret = boot_kobj->show(boot_kobj->data, boot_attr-
>> > > >type, str);
>> > > return ret;
>> > > --
>> > > 2.7.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.




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

Antw: Re: [PATCH] iscsi_ibft,iscsi_boot: remove CAP_SYS_ADMIN restriction for reading entries

[Ulrich Windl]

>>> Dan Williams  schrieb am 04.10.2016 um 18:11 in Nachricht
<1475597465.21760.3.ca...@redhat.com>:
> On Tue, 2016-10-04 at 12:08 -0400, Peter Jones wrote:
>> On Tue, Oct 04, 2016 at 11:03:05AM -0500, Dan Williams wrote:
>> > 
>> > All the iSCSI boot entries are read-only anyway; it's unclear why
>> > the
>> > CAP_SYS_ADMIN restriction is in place since this information isn't
>> > particularly sensitive and cannot be changed.  Userspace
>> > applications
>> > may want to read this without requiring CAP_SYS_ADMIN for their
>> > entire process just for iBFT info.
>> > 
>> > Signed-off-by: Dan Williams 
>> 
>> Uh, because there are login credentials to the target in there.
> 
> Fair enough.  So can we just check CAP_SYS_ADMIN for the login
> credentials, and not check it for all the IP details and such?

The "need to know?" principle: Who needs to know that information?

> 
> Dan
> 
>> > 
>> > ---
>> >  drivers/scsi/iscsi_boot_sysfs.c | 3 ---
>> >  1 file changed, 3 deletions(-)
>> > 
>> > diff --git a/drivers/scsi/iscsi_boot_sysfs.c
>> > b/drivers/scsi/iscsi_boot_sysfs.c
>> > index d453667..4e9c324 100644
>> > --- a/drivers/scsi/iscsi_boot_sysfs.c
>> > +++ b/drivers/scsi/iscsi_boot_sysfs.c
>> > @@ -47,9 +47,6 @@ static ssize_t iscsi_boot_show_attribute(struct
>> > kobject *kobj,
>> >ssize_t ret = -EIO;
>> >char *str = buf;
>> >  
>> > -  if (!capable(CAP_SYS_ADMIN))
>> > -  return -EACCES;
>> > -
>> >if (boot_kobj->show)
>> >ret = boot_kobj->show(boot_kobj->data, boot_attr-
>> > >type, str);
>> >return ret;
>> > -- 
>> > 2.7.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.




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

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

[Ulrich Windl]

>>> The Lee-Man  schrieb am 27.09.2016 um 03:50 in
Nachricht :
> Christoph Hellwig suggested we do away with the open-iscsi google group 
> (this group) and use linux-scsi.

Obviously linux-scsi is more generic.

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




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

Antw: Re: How to encrypt password store in nodes dir

[Ulrich Windl]

>>> The Lee-Man  schrieb am 21.09.2016 um 18:43 in
Nachricht :
> There is no option to encrypt the password and storing in that format.

Also I think if somebodxy is root on the machine, he/she can do more dangerous 
things than reading the iSCSI passwords...

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




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

Antw: iscsi daemon in docker container

[Ulrich Windl]

>>> "Serguei Bezverkhi (sbezverk)"  schrieb am 08.03.2016 um
03:54 in Nachricht :
> Hello,
> 
> As per Michael Christie suggestion, I am reaching out to a wider audience.  
> I am trying to run iscsid inside of a Docker container but without using 
> systemd. When I start iscsid -d 8 -f, it fails with "Cannot bind IPC socket". 
> I would appreciate if somebody who managed to get it working, share his/her 
> steps.

What about stracing iscsid as a first step?

> 
> Thank you
> 
> Serguei
> 
> -- 
> 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.

Antw: Re: [PATCH] iscsi_tcp set SO_LINGER to abort connection for error handling

[Ulrich Windl]

Hi!

I always thought SO_LINGER only has an effect on connections that are 
(partially) closed only: So if there is some network outage on a TCP connection 
and the connection is still considered established, would it help?

Regards,
Ulrich

>>> Chris Leech  schrieb am 04.03.2016 um 06:00 in Nachricht
<20160304050001.cohjmdvxyopzd...@straylight.hirudinean.org>:
> On Thu, Mar 03, 2016 at 07:09:14PM -0600, Mike Christie wrote:
>> On 03/03/2016 06:09 PM, Chris Leech wrote:
>> > When requests are being failed it's important to abort the TCP
>> > connection rather than let TCP wait and attempt a graceful shutdown.
>> > 
>> > That can be accomplished by setting the SO_LINGER socket option with a
>> > linger time of 0 to drop queued data and close the connection with a RST
>> > instead of a FIN.
>> > 
>> > Signed-off-by: Chris Leech 
>> > ---
>> >  usr/io.c | 15 +++
>> >  1 file changed, 15 insertions(+)
>> > 
>> > diff --git a/usr/io.c b/usr/io.c
>> > index f552e1e..48b233c 100644
>> > --- a/usr/io.c
>> > +++ b/usr/io.c
>> > @@ -391,9 +391,24 @@ iscsi_io_tcp_poll(iscsi_conn_t *conn, int timeout_ms)
>> >  void
>> >  iscsi_io_tcp_disconnect(iscsi_conn_t *conn)
>> >  {
>> > +  struct linger so_linger = { .l_onoff = 1, .l_linger = 0 };
>> > +
>> >if (conn->socket_fd >= 0) {
>> >log_debug(1, "disconnecting conn %p, fd %d", conn,
>> > conn->socket_fd);
>> > +
>> > +  /* If the state is not IN_LOGOUT, this isn't a clean shutdown
>> > +   * and there's some sort of error handling going on. In that
>> > +   * case, set a 0 SO_LINGER to force an abortive close (RST) and
>> > +   * free whatever is sitting in the TCP transmit queue. This is
>> > +   * done to prevent stale data from being sent should the
>> > +   * network connection be restored before TCP times out.
>> > +   */
>> > +  if (conn->state != ISCSI_CONN_STATE_IN_LOGOUT) {
>> > +  setsockopt(conn->socket_fd, SOL_SOCKET, SO_LINGER,
>> > + _linger, sizeof(so_linger));
>> > +  }
>> > +
>> >close(conn->socket_fd);
>> >conn->socket_fd = -1;
>> >}
>> > 
>> 
>> Nice.
>> 
>> For maybe a slightly different problem, but hoping I get lucky and your
>> patch fixes it too, I thought the network layer was still accessing
>> pages that we tried to send and was causing a oops. I get the part where
>> with your patch the network layer will not try to send data anymore, but
>> I guess I am asking if the network layer could still be doing some sort
>> of delayed cleanup process after close() has returned?
> 
> From what I can tell in the tcp code, the zero linger handling purges
> all of the socket queues freeing everything before close returns.
> 
> - 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.




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

Antw: persistant record layout and long DNS names

[Ulrich Windl]

>>> Chris Leech  schrieb am 19.02.2016 um 23:42 in Nachricht
<20160219224215.422q6isrsar6v...@straylight.hirudinean.org>:
> I was asked an interesting question recently, and thought I'd share it
> here. I don't think it's critical to address right away, but surprising
> and something to think about.
> 
> Someone asked me about targets configured to return DNS names rather
> than IP addresses in a SendTargets response, and what the maximum length
> of a response Open-iSCSI would accept was. Obviously they had tested
> this and hit an issue or they wouldn't be asking.
> 
> It turns out that DNS names have a limit of 253 octets when converted to
> a string. When we store a node record we append the port and tpgt as
> part of the filename. That potentially takes up to 12 characters, two
> 16-bit values that might need 5 chars each + 2 commas. Basically all
> Linux filesystems have a 255 byte filename limit, so any DNS name of
> longer than 243 bytes (10 less than the DNS limit) will fail to create a
> node record.

IFF you use the host name for the record directly; if you'd hash the host name 
(MD5 oder so), the length wouldn't matter. Listing all the host names is a bit 
tricky, however.

> 
> The discovery symlinks are much worse, as we try and put the target
> name, address, port, tpgt, and iface name all together.

Something completely different: What about replacing the complex directory and 
file structure with a real database like sqlite?

Regards,
Ulrich

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




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

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

[Ulrich Windl]

>>> Christian Seiler  schrieb am 13.02.2016 um 01:05 
>>> in
Nachricht <56be734d.1000...@gmail.com>:
> Hi,
> 
> Debian is currently working on making the entire archive build
> reproducibly.  is a good
> resource describing the motivation behind this effort.
> 
> There was one problem that was found in the open-iscsi package
> build system that prevented builds from being reproducible:
> the list of object files generated by the wildcard Makefile
> function are not in a deterministic order, causing changes in
> the output depending on the order in the underlying filesystem.

Hi!

I wonder: Would adding those objects to an object library (and use that library 
to add the needed objects) also fix this problem? (I thought objects in a 
library are sorted)

> 
> I've attached a patch against the current git master that
> sorts the list of object files within the Makefile, making the
> order deterministic and allowing reproducible builds to be
> made. See also:
> 
> 
> It would be great if you could apply this patch upstream, so we
> don't have to carry it in Debian.
> 
> Thanks!
> 
> 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.




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

Antw: Re: [PATCH] make use of all 24 bits of ISID qualifier space

[Ulrich Windl]

>>> Chris Leech  schrieb am 10.02.2016 um 22:51 in Nachricht
<20160210215131.ge9...@straylight.hirudinean.org>:

[...]
> Do we really want to do anything other than limit to the 24-bits that we
> can place into an ISID?

I think not having any "artificial" limits is a good idea. If we run out of 
memory, wen just have to handle the case properly and report it back to the 
operator.

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

Antw: Re: login times when scaling out targets (Re: ISID uniqueness)

[Ulrich Windl]

>>> Chris Leech  schrieb am 10.02.2016 um 03:53 in Nachricht
<20160210025324.gb9...@straylight.hirudinean.org>:
> On Tue, Feb 09, 2016 at 03:24:04PM -0800, Chris Leech wrote:
>> But there may be more straightforward gains to be had in cleaning up the
>> sysfs code.  Every attribute read ends up in 
> sysfs_lookup_devpath_by_subsys_id
>> which does a bunch of string ops and stats trying to find the device
>> path.  Even keeping the subsystem location general as it is, if we find
>> things once and remember the path for all the attribute reads it should
>> help a lot.
> 
> On the right track but that still wasn't exactly the big issue.
> It's the attribute cache.  It grows without bounds, and the lookup is
> just a linear walk through a linked list with a strcmp against each
> node.

A linear search in a "cache" sounds like a bad idea anyway: Why not do some 
hashing?

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




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

Antw: iscsiadm didn't discovery the LUNs when LUN0 is removed

[Ulrich Windl]

Hi!

I don't know the recent specs, but years ago we had a disk system (not iSCSI) 
where the documentation said LUN 0 must always exist. So we created a small 
dummy LUN that nobody actually used, but it was visible to every system.

Maybe that helps.

Regards,
Ulrich

>>> RenShu Xiao  schrieb am 03.02.2016 um 20:11 in 
>>> Nachricht
:
> Hi 
> 
> in the target server, I have 2 luns in one host and I removed LUN0 and 
> using iscsiadm log in fine but the disks won't be discovered. Hence can't 
> be mounted.
> 
> The following listed the network trace. Target responded check condition 
> for LUN0 inquiry and expect report all from initiator.
> 
> Do we miss something here? or is this a known issue of open-iscsi?
> 
> Thanks,
> 
> Frank
> 
> 
> 
> 
> -- 
> 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.

Antw: Re: Possible issue in commit 659743b02c41 ("libiscsi: Reduce locking contention in fast path")

[Ulrich Windl]

>>> Chris Leech  schrieb am 06.11.2015 um 01:56 in Nachricht
<20151106005608.ga18...@straylight.hirudinean.org>:

[...]
> Am I missing something, or is splitting a linked list across two locks a
> major failing of this change?
[...]

Could you explain your question again for those that are not deeply in the code?
How do you lock, and what do you do between the locks?

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.

Antw: systemd files for open-iscsi

[Ulrich Windl]

Hi!

A somewhat unrelated question: With all these partial orderings (specified by 
"before" and "After" in the systemd unit files) is there a test suite that 
tries all allowable combinations that fulfill the partial ordering? Just in 
case the ordering is too weak?

Regards,
Ulrich

>>> The Lee-Man  schrieb am 10.09.2015 um 18:18 in
Nachricht <4d5e3390-9a37-4d0d-8116-dc51aeaf6...@googlegroups.com>:
> 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 

Antw: [PATCH v2 1/2] iscsid: Changes to support ping through iscsiuio

[Ulrich Windl]

 adheer.chandravan...@qlogic.com schrieb am 09.07.2015 um 13:38 in 
 Nachricht
1436441896-7161-2-git-send-email-adheer.chandravan...@qlogic.com:
 From: Adheer Chandravanshi adheer.chandravan...@qlogic.com
 
 These changes are done in order to support ping operation for drivers
 like bnx2i that use iscsiuio.
 
 Signed-off-by: Adheer Chandravanshi adheer.chandravan...@qlogic.com
 ---
  usr/iscsiadm.c |   38 +++---
  usr/iscsid_req.c   |   38 +-
  usr/iscsid_req.h   |2 +-
  usr/transport.c|1 +
  usr/transport.h|3 +++
  usr/uip_mgmt_ipc.c |   38 +-
  usr/uip_mgmt_ipc.h |   13 +
  7 files changed, 119 insertions(+), 14 deletions(-)
 
 diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c
 index aa7cf07..495af3a 100644
 --- a/usr/iscsiadm.c
 +++ b/usr/iscsiadm.c
 @@ -3099,10 +3099,10 @@ static char *iscsi_ping_stat_strs[] = {
   No ARP response received,
  };
  
 -static char *iscsi_ping_stat_to_str(uint32_t status)
 +static char *iscsi_ping_stat_to_str(int status)
  {
   if (status  0 || status  ISCSI_PING_NO_ARP_RECEIVED) {
 - log_error(Invalid ping status %u, status);
 + log_error(Ping error: %s\n, strerror(status));

status does not look very much like errno, but isn't strerror() defined for 
 errno values?


   return NULL;
   }
  
[...]

Regards,
Ulrich


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

Antw: Re: [PATCH] Reformat man page synopsis sections

[Ulrich Windl]

I can remember having read it, but I can't remember whether I was on CC:. I 
looked it up: It seems I received it from the list.


 Mike Christie micha...@cs.wisc.edu schrieb am 02.06.2015 um 19:40 in
Nachricht 556dea77.4080...@cs.wisc.edu:
 Can other people see the original email below on the list? I got a mail,
 but I am not seeing it on the open-iscsi list web interface.
 
 On 05/31/2015 04:03 AM, Christian Seiler wrote:
 Hi,
 
 (Hoping this gets through, Google Groups has recently rejected
 messages by me for no apparent reason.)
 
 Thanks for your suggestions.
 
 On 29.05.2015 08:49, Ulrich Windl wrote:
 A comment on likes like this:
 +\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P 
 printlevel ]

 I think such lines should be restructured for redability and better 
 diff-ing 
 like this:
 
 I've created a patch that implements this for iscsiadm.8 and attached it
 to this email. The patch applies on top of the escaping fixes of 4/4.
 
 Best 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 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: Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside

[Ulrich Windl]

 Christian Seiler christ...@iwakd.de schrieb am 31.05.2015 um 11:32 in
Nachricht 556ad51a.9080...@iwakd.de:

[...]
 I disagree here vehemently that it's only useful for development (in
 fact, I would assert that it's rather useless for development and only
 really useful in production), but this would go off a tangent, so I'll
 leave it at that.

IMHO it depends on whom you expect to find the bugs: The developer or the 
customer.
Sadly, in the past years most software lets the customer find the bugs (If you 
need a popular example, just count the critical messages produced by GNOME)

[...]
 And perhaps more importantly, that's not clear to me at all after
 re-reading your emails: do you object to my patch? Or are you just
 throwing general ideas around?

People are always upset when you question their changes, maybe it's just that.

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.

Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside

[Ulrich Windl]

Hi!

Some remarks on the CFLAGS thing:
In one of my projects I used this approach for messing with CFLAGS:
--
CFLAGS=-pthread
CWARNFLAGS=-Wall -Wextra -Wshadow
COPTFLAGS=-pipe -O2
CDEBUGFLAGS=-g -fstack-protector-all
CFLAGS+=$(CWARNFLAGS)
CFLAGS+=$(COPTFLAGS)
#CFLAGS+=$(CDEBUGFLAGS)
LDFLAGS=-lpthread -lrt
--
It's somewhat GNU-makish, but you can easily switch CFLAGS by (un)commenting 
some of the CFLAGS+=  lines. The linking rule then is $(CC) $(CFLAGS) 
$(LDFLAGS) -o $@ $^

So my CFLAGS are the absolute minimum required for a correct compile, and 
everything else are extras.

And if you need defines they should go to CPPFLAGS. GNU makes built-in rules 
look like
LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
PREPROCESS.S = $(CC) -E $(CPPFLAGS)
COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c

Maybe someone wants to restructure CFLAGS like that...

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.

Antw: [PATCH 4/4] Spelling and escaping error fixes.

[Ulrich Windl]

Hi!

A comment on likes like this:
 +\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P printlevel 
 ]

I think such lines should be restructured for redability and better diff-ing 
like this:

.B iscsiadm
.B \-m discoverydb
.RB [ \-hV ]
.RB [ \-d
.IR debug_level ]
.RB [ \-P
.IR printlevel ]

Note: I changed debug_level and print_level to italics, because they are not 
literal (as discoverydb) but placeholders. I put literal option in bold face. 
I also removed space inside [...], because it's not necessary and it shortens 
the line.

Form man 7 man-pages:
---
   SYNOPSIS  briefly  describes  the  command or function's interface.
 For commands, this shows the syntax of  the  command  and
 its  arguments  (including options); boldface is used for
 as-is text and italics are used to  indicate  replaceable
 arguments.   Brackets  ([])  surround optional arguments,
 vertical bars (|) separate choices,  and  ellipses  (...)
 can  be  repeated.   For functions, it shows any required
 data declarations or #include directives, followed by the
 function declaration.
---

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: Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside

[Ulrich Windl]

 Christian Seiler christ...@iwakd.de schrieb am 29.05.2015 um 12:43 in
Nachricht 556842d3.8070...@iwakd.de:
 On 05/29/2015 08:19 AM, Ulrich Windl wrote:
 Some remarks on the CFLAGS thing:
 In one of my projects I used this approach for messing with CFLAGS:
 --
 CFLAGS=-pthread
 CWARNFLAGS=-Wall -Wextra -Wshadow
 COPTFLAGS=-pipe -O2
 CDEBUGFLAGS=-g -fstack-protector-all
 CFLAGS+=$(CWARNFLAGS)
 CFLAGS+=$(COPTFLAGS)
 #CFLAGS+=$(CDEBUGFLAGS)
 LDFLAGS=-lpthread -lrt
 --
 It's somewhat GNU-makish, but you can easily switch CFLAGS by
 (un)commenting some of the CFLAGS+= lines.
 [...]
 So my CFLAGS are the absolute minimum required for a correct compile,
 and everything else are extras.
 
 The code you posted has the opposite effect of what my patch wants to
 achieve. There appears to be some confusion as to the purpose of my
 patch, so maybe I should go a bit into detail about what the point here
 is.

I'm not sure. Also I was posting an idea rather than concrete code.

 
 When compiling software, either for distributions that want to create a
 package from it, or for end users that want to call it, one will often
 want to set some global compiler and linker flags to influence package
 build.
 
  - Sometimes you need to debug something and disable optimization for
that. Then you might need want to rebuild a package with a different
-O level than the package typically has. Of course, one can
tediously look at the means that different software provides to do
so (if at all) - or one can just assume that setting CFLAGS=-O0
before running configure / make will do the trick.

Yes, but someone could also define `CC=gcc -O0' and it might work. My 
proposal was mostly _against_ such misusing of flags. Also, you cannot easily 
_add_ flags to the existing set of flags. My proposal makes it  somewhat easier 
at least.

 
  - When compiling with a compiler other than gcc, you might need to add
some flags in order to make it work.

See above.


  - There is a goal to harden as much software as possible in Debian, so
there's a recommendation that things like -fstack-protector-strong
are to be used (unless the software doesn't work otherwise).

IMHO this is useful for the developer to fix his/her bugs, but for production 
systems it will just make software bigger and slower.

 
 It has long been standard practice among open source projects that if
 external CC, CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, ... are supplied when
 building, those flags will influence the build. So what one typically
 does is partition the CFLAGS into to sets: those required for
 compilation (such as -pthread) and a default set of flags if no
 external ones are specified.

Agree.

 
 For example, if you use a default autoconf + automake setup, these will
 typically set -O2 -g as the default set of flags (if on gcc and the
 compiler supports -g). But if one does
 CFLAGS=-sometingelse ./configure
 or
 ./configure CFLAGS=-sometingelse
 it will use -somethingelse instead of -O2 -g. Same thing with the other
 environment variables.
 
 And those flags that are required to make the package compile should
 simply be added to the current set of flags. In a standard autoconf and
 automake setup, you can do it in configure.ac along the
 lines of:
 CFLAGS+= -additional-flags

This may solve one of the problems described above.

 (Of course, checking that the compiler supports your flag is always
 better, there is a macro for that; and things like pthread actually
 have a standardized macro that do that automatically.)
 Alternatively, you can set it directly in Makefile.am via
 AM_CFLAGS = -additional-flags
 which will automatically be added to the list of flags.

With all these solutions we have the problem that the user who compile 
(configres) the software has to be kind of an expert to know al the flags and 
syntaxes. You probably are such an expert. I don't know all of these.

 
 Since this is somewhat standardized, this has the great advantage that
 you don't need to invest time into figuring out how each different
 piece of software requires to change its own build flags. If you
 package things for your distribution, there are often a lot of
 automatisms that use this mechanism to provide set default set of
 flags - and you don't have to do anything for all these things to just
 work[tm]. But if a package doesn't do it the standard way, then you
 have to work around all these sorts of things.
 
 But your piece of code goes even further than than a custom mechanism:
 it doesn't provide a way to influence CFLAGS externally at all! With a

As I said: This is part of a project I created and I simply had no necessity to 
incluence the flags from outside the Makefile.

 custom mechanism, you can figure it out (both as a user that wants
 to compile it as well as a packager) and then use it. But if you
 hard-code CFLAGS = ... in your Makefile (as per your example), one
 actually needs to patch the software to achieve this goal.
 
 Now

Q: automatic remove of down devices?

[Ulrich Windl]

Hello!

Today we rebooted our FibreChannel storage that is accessed via iSCSI. Since 
then (the storage is up again) syslog is filled with messages like these:
...
Jan 16 14:30:31 o1 multipathd: VM-E2: sdbs - tur checker reports path is down
Jan 16 14:30:31 o1 multipathd: cLVM-E2: sdbw - tur checker reports path is down
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
...

Shortly after the storage was down I saw these messages in syslog:
Jan 16 13:22:01 o1 kernel: [781809.177434] device-mapper: multipath: Failing 
path 68:192.
Jan 16 13:22:02 o1 multipathd: sdbi: No fc_remote_port device for 'rport-24:0-0'
Jan 16 13:22:03 o1 multipathd: sdd: No fc_remote_port device for 'rport-5:0-0'

So I guess multipathd tries to remove the down device, but fails to realize 
that it's an iSCSI (not FC) device.
So is this (removal of stale devices) possible?

I tried a rescan-scsi-bus.sh -r, but still I see these:
Jan 16 14:34:27 o1 iscsid: conn 0 login rejected: target error (03/01)
Jan 16 14:34:27 o1 iscsid: conn 0 login rejected: target error (03/01)

(The iSCSI gateway was never restarted; just the FC- backend)

Is this a problem in open-iscsi (SLES11 SP3: open-iscsi-2.0.873-0.23.1)? (After 
Reboot everything looked clean again)

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.

Antw: [PATCH 4/5] iscsiuio CFLAGS fixes

[Ulrich Windl]

 Ulrich Windl ulrich.wi...@rz.uni-regensburg.de schrieb am 14.01.2015 um
08:45 in Nachricht 54b62c9d02a100018...@gwsmtp1.uni-regensburg.de:
 Chris Leech cle...@redhat.com schrieb am 12.01.2015 um 20:24 in Nachricht
 1421090651-8333-5-git-send-email-cle...@redhat.com:
 try and keep existing CFLAGS from environment for packagers
 ---
  iscsiuio/configure.ac | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/iscsiuio/configure.ac b/iscsiuio/configure.ac
 index d619598..7ee1e73 100644
 --- a/iscsiuio/configure.ac
 +++ b/iscsiuio/configure.ac
 @@ -53,7 +53,7 @@ AC_LIBTOOL_DLOPEN
  # libtool stuff
  AC_PROG_LIBTOOL
  
 -CFLAGS=-O2 -Wall
 +CFLAGS=${CFLAGS} -O2 -Wall
 
 Don't you have to use either += or := for that? See 6.6 Appending More 
 Text to Variables in the GNU make info...

Sorry, I didn't look close: It's autoconfigure, not Make...


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

Antw: [PATCH 4/5] iscsiuio CFLAGS fixes

[Ulrich Windl]

 Chris Leech cle...@redhat.com schrieb am 12.01.2015 um 20:24 in Nachricht
1421090651-8333-5-git-send-email-cle...@redhat.com:
 try and keep existing CFLAGS from environment for packagers
 ---
  iscsiuio/configure.ac | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/iscsiuio/configure.ac b/iscsiuio/configure.ac
 index d619598..7ee1e73 100644
 --- a/iscsiuio/configure.ac
 +++ b/iscsiuio/configure.ac
 @@ -53,7 +53,7 @@ AC_LIBTOOL_DLOPEN
  # libtool stuff
  AC_PROG_LIBTOOL
  
 -CFLAGS=-O2 -Wall
 +CFLAGS=${CFLAGS} -O2 -Wall

Don't you have to use either += or := for that? See 6.6 Appending More 
Text to Variables in the GNU make info...


  ## check for --enable-debug first before checking CFLAGS before
  ## so that we don't mix -O and -g
  AC_ARG_ENABLE(debug,
 -- 
 2.1.0
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to open-iscsi+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.




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

Antw: [PATCH 2/5] add discovery as a valid mode in iscsiadm.8

[Ulrich Windl]

 Chris Leech cle...@redhat.com schrieb am 12.01.2015 um 20:24 in Nachricht
1421090651-8333-3-git-send-email-cle...@redhat.com:
 ---
  doc/iscsiadm.8 | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/doc/iscsiadm.8 b/doc/iscsiadm.8
 index 9a945d1..05793b2 100644
 --- a/doc/iscsiadm.8
 +++ b/doc/iscsiadm.8
 @@ -174,13 +174,13 @@ for session mode).
  .TP
  \fB\-m, \-\-mode \fIop\fR
  specify the mode. \fIop\fR
 -must be one of \fIdiscoverydb\fR, \fInode\fR, \fIfw\fR, \fIhost\fR 
 \fIiface\fR or \fIsession\fR.
 +must be one of \fIdiscovery\fR, \fIdiscoverydb\fR, \fInode\fR, \fIfw\fR, 
 \fIhost\fR \fIiface\fR or \fIsession\fR.
  .IP
 -If no other options are specified: for \fIdiscoverydb\fR and \fInode\fR, 
 all
 -of their respective records are displayed; for \fIsession\fR, all active
 -sessions and connections are displayed; for \fIfw\fR, all boot firmware
 -values are displayed; for \fIhost\fR, all iSCSI hosts are displayed; and
 -for \fIiface\fR, all ifaces setup in /etc/iscsi/ifaces are displayed.
 +If no other options are specified: for \fIdiscovery\fR, \fIdiscoverydb\fR 
 and
 +\fInode\fR, all of their respective records are displayed; for 
 \fIsession\fR,
 +all active sessions and connections are displayed; for \fIfw\fR, all boot
 +firmware values are displayed; for \fIhost\fR, all iSCSI hosts are 
 displayed;
 +and for \fIiface\fR, all ifaces setup in /etc/iscsi/ifaces are displayed.
  
  .TP
  \fB\-n\fR, \fB\-\-name=\fIname\fR

Hi!

A matter of style: I think these font escape sequences like \fI make the 
manual source quite hard to read, and most likely this is why there exist some 
macros for that. So instead of writing (just one example)
--
.TP
\fB\-n\fR, \fB\-\-name=\fIname\fR
--
use
--
.TP
.BR \-n ,
.BR \-\-name= name
--

Maybe someone is willing to beautify the manual page thats way.

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.

Antw: Issue seeing targets when using discovery with the IP Address.

[Ulrich Windl]

Stupid question: What is the result of nslookup the_xxx_IP_address? Does it 
work as intended?

 Jonathan Payne fallinga...@gmail.com schrieb am 23.12.2014 um 14:59 in
Nachricht 40060add-e3af-449d-93a0-b73ad54ed...@googlegroups.com:
 Hello everyone,
 
 
 I'm having an issue with two Ubuntu servers in our ExacqVision security 
 camera setup. Our camera server is unable to see the extended storage 
 device, when iSCSIADM is run with the following command:
 
 sudo iscsidm -m discovery -t st -p xxx.xxx.xxx.xxx:3260
 
 
 It returns the following error: 
 
 iscsiadm: Cannot resolve host . getaddrinfo error: [Name or service not 
 known]
 
 iscsiadm: cannot resolve host name
 iscsiadm: Could not perform SendTargets discovery.
 
 
 
 However if I plugin the hostname where the IP is the host name returns the 
 targets. I believe this is our problem with our camera software not 
 connecting to the device, as it will not allow you to use the hostname when 
 connecting the iSCSI targets, only the IP address.
 
 Any help would be greatly appreciated!
 
 
 
 Thank you!
 
 -- 
 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.




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

Antw: Linux kernel development reports for the 3.17 release

[Ulrich Windl]

 Greg KH g...@kroah.com schrieb am 14.12.2014 um 21:16 in Nachricht
20141214201653.ga18...@kroah.com:

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

Hi!

Maybe I'm missing the obvious, but if you address a mailing list and want to 
address  one or more persons specifically, I think you've got to name them 
instead of addressing them with you...

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.

Antw: Re: Slow dir / Performance.

[Ulrich Windl]

Does man blktrace sound useful to you? With this command and others you can 
produce funny output like this:
9-1  AW271   68123744   16   153.802866844 1  1057 xfsbufd/dm-12
9-1  QW272   68123744   16   153.802871575 1  1057 xfsbufd/dm-12
9-1  AW273  161876032   16   153.802877568 1  1057 xfsbufd/dm-12
9-1  QW274  161876032   16   153.802877938 1  1057 xfsbufd/dm-12

(the above example is tracing an MD-RAID1)

The RAID leg in a virtual machine produces output like this:
202-80  Q   WS496   63353637   8811.636835786 0   799 md1_raid1
202-80  G   WS497   63353637   8811.636837191 0   799 md1_raid1
202-80  Q   WS498   63353725   2911.636838296 0   799 md1_raid1
202-80  G   WS499   63353725   2911.636838924 0   799 md1_raid1
202-80  I   WS500   63353555   8211.636854804 0   799 md1_raid1
202-80  I   WS501   63353637   8811.636855654 0   799 md1_raid1
202-80  I   WS502   63353725   2911.636855895 0   799 md1_raid1

A crude sketch of commands to produce the files like above is:
ACTIONS=$(echo 'issue,complete,read,write' |
 sed -e 's/,/ -a /g; s/^/-a /')
trace()
{
blktrace -d $1 $ACTIONS -w $2 -o - |
blkparse -i - -f '%M-%m %2a %4d %10s %10S %4n %5T.%t %c %5p %C\n' -o $3 
}
#...
: ${OBASE:=/tmp/blocktrace-}
OUTFILE=${OBASE}$(date -u '+%Y%m%d_%H%M')-${NAME}.out
echo trace $DEV ($NAME) to $OUTFILE for $DURATION seconds
trace /dev/${DEV#/dev/} $DURATION $OUTFILE

Regards,
Ulrich

 Stefan B stefj...@gmail.com schrieb am 09.12.2014 um 09:22 in Nachricht
fcc4fab0-7f1d-4070-85fe-99803c76a...@googlegroups.com:
 Thanks for the messages,
 
 I have change the open-iscsi settings with Citrix Perfomance settings, and 
 i have set the blockdev to 16384, i see more perfomance.
 
 But the first dir or commando on the dir, give the same slow perfomace, it 
 wil be taken more than 30 secondes.
 
 We not running any nis or radius server.
 
 On Wednesday, December 3, 2014 8:24:06 AM UTC+1, Uli wrote:

  stef...@gmail.com javascript: schrieb am 02.12.2014 um 15:06 in 
 Nachricht 
 5a7097b3-0dd7-4c28-abbf-ff66800b8...@googlegroups.com javascript:: 
  We have 2 Equallogic Systems, And a Dell Servers. 
  
  We have every server give a block device home dir , so the user data are 
 on 
  the home dir this is working great its format on xfs filesystem, and 
  running iscsiadm version 2.0-870 with linux kernel 3.10.57 
  
  But when we logging on the server, the first time we do a dir command on 
  the home dir, its take a long time when we get feedback on the dir , the 
  next time is fast when we do a dir. 

 Are you sure it's related to iSCSI? Especially for the /home dire several 
 different UIDs/GIDs are involved. We had a slow ls -l /home performance 
 when the NIS server had a problem. Maybe you use LDAP or something else? 
 Maybe try hdparm -t block_device to get a rough number how fast your 
 block device can be read. I know there are better tests, but this one is 
 quick and easy to perform... 

  Now we have users on this systems and this problem give not good 
  performance on sql and websites an e-mail we are running on the server. 

 You are running a database (sql) via iSCSI? 

  
  Are the some information how i can fix ore maybe get this problem better 
  under control ? 
  
  I hope so that somebody can help me, i am searching for more than 3 
 weeks 
  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+...@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.



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

Antw: Slow dir / Performance.

[Ulrich Windl]

 stefj...@gmail.com schrieb am 02.12.2014 um 15:06 in Nachricht
5a7097b3-0dd7-4c28-abbf-ff66800b8...@googlegroups.com:
 We have 2 Equallogic Systems, And a Dell Servers.
 
 We have every server give a block device home dir , so the user data are on 
 the home dir this is working great its format on xfs filesystem, and 
 running iscsiadm version 2.0-870 with linux kernel 3.10.57
 
 But when we logging on the server, the first time we do a dir command on 
 the home dir, its take a long time when we get feedback on the dir , the 
 next time is fast when we do a dir.

Are you sure it's related to iSCSI? Especially for the /home dire several 
different UIDs/GIDs are involved. We had a slow ls -l /home performance when 
the NIS server had a problem. Maybe you use LDAP or something else? Maybe try 
hdparm -t block_device to get a rough number how fast your block device can 
be read. I know there are better tests, but this one is quick and easy to 
perform...

 Now we have users on this systems and this problem give not good 
 performance on sql and websites an e-mail we are running on the server.

You are running a database (sql) via iSCSI?

 
 Are the some information how i can fix ore maybe get this problem better 
 under control ?
 
 I hope so that somebody can help me, i am searching for more than 3 weeks 
 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.




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

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

[Ulrich Windl]

 The Lee-Man leeman.dun...@gmail.com schrieb am 24.11.2014 um 18:04 in
Nachricht dfb5172f-05e8-4027-867e-8e2b1969f...@googlegroups.com:
[...]
 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)

 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.

 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.

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

[Ulrich Windl]

 The Lee-Man leeman.dun...@gmail.com schrieb am 20.11.2014 um 18:07 in
Nachricht dc3f5a91-d2a1-41e1-bc93-e5d9f44ba...@googlegroups.com:
 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.

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

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

 
 
 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.

That why I questioned the sort in the beginning.

 
 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.  

I'm not saying your fix is not effective; I was just wondering whether you 
really fixed the root of the problem.

 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 

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

[Ulrich Windl]

 The Lee-Man leeman.dun...@gmail.com schrieb am 19.11.2014 um 19:35 in
Nachricht 16860f30-b55c-4106-a4e1-d7badfc36...@googlegroups.com:
 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. 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.

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.


 
 
  
  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.




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

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

[Ulrich Windl]

 Lee Duncan leeman.dun...@gmail.com schrieb am 18.11.2014 um 22:35 in
Nachricht 1416346536-18198-1-git-send-email-leeman.dun...@gmail.com:
 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.

 
 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.dun...@gmail.com
 
 -- 
 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.




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

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

[Ulrich Windl]

Hi!

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

Regards,
Ulrich

 Lee Duncan leeman.dun...@gmail.com schrieb am 15.11.2014 um 02:15 in
Nachricht 1416014130-25502-7-git-send-email-leeman.dun...@gmail.com:
 From: Hannes Reinecke h...@suse.de
 
 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 h...@suse.de
 ---
  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_PREFIX iqn.1967-12.
 +#else
 +#define DUMMY_IQN_PREFIX IQNPREFIX
 +#endif
  
  static uint32_t  isns_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+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.




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