Antw: [PATCH 7/7] actor: Don't wake up poll() on a timeout if we don't need to

>>> Chris Leech schrieb am 12.06.2013 um 07:24 in Nachricht <1371014686-22334-8-git-send-email-cle...@redhat.com>: [...] > diff --git a/usr/event_poll.c b/usr/event_poll.c > index f36fec1..dcbb79a 100644 > --- a/usr/event_poll.c > +++ b/usr/event_poll.c > @@ -121,17 +121,37 @@ static int shutdown_

Antw: [PATCH 5/7] actor: Unobfuscate ACTOR_MAX_LOOPS

Hi! While most of your changes seem reasonable, this one (if ACTOR_MAX_LOOPS will ever be different from 1) may be discussable. One rule of software negineering says: "never use a literal constant (except when defining a symbolic one ;-)" Regards, Ulrich >>> Chris Leech schrieb am 12.06.2013

[PATCH 5/7] actor: Unobfuscate ACTOR_MAX_LOOPS

From: Adam Jackson Signed-off-by: Adam Jackson --- usr/actor.c | 2 +- usr/actor.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/usr/actor.c b/usr/actor.c index e4e8a24..c084176 100644 --- a/usr/actor.c +++ b/usr/actor.c @@ -240,7 +240,7 @@ actor_poll(void) /* don

[PATCH 1/7] actor: Mark actor_check static

From: Adam Jackson Signed-off-by: Adam Jackson --- usr/actor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr/actor.c b/usr/actor.c index b8f8e61..880bf81 100644 --- a/usr/actor.c +++ b/usr/actor.c @@ -199,7 +199,7 @@ actor_timer_mod(actor_t *thread, uint32_t timeout, v

[PATCH 3/7] actor: s/ACTOR_TICKS/actor_jiffies/

From: Adam Jackson No reason to obscure this. Signed-off-by: Adam Jackson --- usr/actor.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/usr/actor.c b/usr/actor.c index fb90924..9c2f449 100644 --- a/usr/actor.c +++ b/usr/actor.c @@ -38,7 +38,6 @@ static volatile uin

[PATCH 6/7] actor: Simplify actor_poll a little

From: Adam Jackson Finally, a functionality change. Having expanded ACTOR_MAX_LOOPS it's now obvious that we were basically only doing actor_check() on every other call. Also, the commentary is just wrong on many levels, we'd only get called about every 250ms anyway. Just call actor_check ever

[PATCH 7/7] actor: Don't wake up poll() on a timeout if we don't need to

Have actor_poll take an indication from the outer event loop of how many ticks of ACTOR_RESOLUTION have passed, and return how many ticks into the future it would like to be called again. Then in event_loop, try and keep the poll timeouts as long as possible without delaying actors or screwing up

[PATCH 4/7] actor: Remove ACTOR_TICKS_10MS()

From: Adam Jackson Again, just obfuscation. Signed-off-by: Adam Jackson --- usr/actor.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/usr/actor.c b/usr/actor.c index 9c2f449..e4e8a24 100644 --- a/usr/actor.c +++ b/usr/actor.c @@ -38,7 +38,6 @@ static volatile uint64_t

[PATCH 2/7] actor: simplify actor_check

From: Adam Jackson Now that it's static we know it can't ever be called when poll_in_progress is true. Signed-off-by: Adam Jackson --- usr/actor.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/usr/actor.c b/usr/actor.c index 880bf81..fb90924 100644 --- a/

iscsid: stop 250ms actor poll when idle

iscsid doesn't need to wake up every 250ms, we can drive the polling of the actor callbacks only when they are needed. Passing on the prep patches as they were sent to me by Adam Jackson, but I've reworked the final event loop changes to keep the time keeping for scheduled actors from falling apar

Re: iSCSI and multipath failover

Thanks Mike. I have few follow-up question please. Why is this default replacement timeout so high. If I understand correctly in a multipath environment it is perfectly alright to set it to 0 without any side effect. The other question is, how early iSCSI can detect session error , be it with tra

[PATCH] iscsid: fix order of setting uid/gid and drop supplementary groups

If using the user and group ID settings together the existing order of calling setuid first will almost always cause the setgid call to fail, assuming the new effective user id does not have the CAP_SETGID capability. The effective group ID needs to change first. While we're at it, if iscsid is s

Re: iSCSI and multipath failover

On 06/07/2013 12:55 AM, Bubuli Nayak wrote: > Hello experts, > > I have learnt from MIke and others comment that multipath failover would > be driven by nop timout + nop interval + replacement_timeout seconds. > > My question is what is the impact I set replacement_timeout to 0. I know > if NOPOU

iSCSI and multipath failover

Hello experts, I have learnt from MIke and others comment that multipath failover would be driven by nop timout + nop interval + replacement_timeout seconds. My question is what is the impact I set replacement_timeout to 0. I know if NOPOUT interval is low , more frequently iSCSI initiator woul

do discovery through SW transports too

Hi Mike, There are iser environments where we might need to do iscsi discovery over rdma connection, that is establish iser connection and then carry the discovery session over it. I was a bit away for the developments in the initiator over the last months so would need some crash help here.

iSCSI and multipath failover

Hello experts, I have learnt from MIke and others comment that multipath failover would be driven by nop timout + nop interval + replacement_timeout seconds. My question is what is the impact I set replacement_timeout to 0. I know if NOPOUT interval is low , more frequently iSCSI initiator would

do the undoable - survive network disconnections under heavy load

Hey, I've a system which uses open-iscsi and mpp driver, to connect an external storage. The system reads data from all disks, and writes to some of them. Kernel is 2.6.27, but latest open-iscsi and mpp. When the storage is down, the system cannot umount some of the disks, and the application

rhel6.3 - iscsid's ability to reconnect after "server restart, or service restart" (open-iscsi 2.0-872.41)

Hi! rhel6.3 (unpatched) iscsistart version 2.0-872.41.el6 iscsid version 2.0-872.41.el6 iscsi-initiator-utils-6.2.0.872-41.el6.x86_64 We use rhel6.3 as diskless clients (iscsi) against our NetApp. Connecting through iBFT with iPXE at BIOS level. Adjusting "node.session.timeo.replacement_time

iscsi initiaor, obsolete volumes remain zombie

Hi, I am new to iscsi. The iscsi in normal environment works fine. Both target and initiators are running on ubuntu. When a new lun is added to a target, it automatically appears on the initiators. But when a lun is removed on the target side, it is remain a zombie, on the initiator. Is there a

Re: do discovery through SW transports too

On 06/06/2013 18:01, Mike Christie wrote: I think everything should be there. I thought I worked on iser when doing the work too. You need the attached kernel patch. In the other mails I think I said you need a change to the userspace iser code, but ignore that. In the common iscsi code I did a

Re: do discovery through SW transports too

On 06/06/2013 18:01, Mike Christie wrote: However, above I am not talking about that or doing discovery over a normal session in general. I was just trying to get clarification for what you wanted. I was not sure if there was some new iser spec stuff that I missed and you wanted to implement. H

Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support

On Tue, 2013-06-11 at 13:26 -0500, Mike Christie wrote: > On 06/11/2013 12:43 PM, Eddie Wai wrote: > > > > On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: > >> On 6/10/13 10:47 PM, Vikas Chaudhary wrote: > >>> > >>> > >>> -Original Message- > >>> From: Eddie Wai > >>> Date: Wedne

Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support

On 06/11/2013 12:43 PM, Eddie Wai wrote: > > On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: >> On 6/10/13 10:47 PM, Vikas Chaudhary wrote: >>> >>> >>> -Original Message- >>> From: Eddie Wai >>> Date: Wednesday 5 June 2013 7:00 AM >>> To: "shyam_i...@dell.com" >>> Cc: "open-iscsi

Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support

On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: > On 6/10/13 10:47 PM, Vikas Chaudhary wrote: > > > > > > -Original Message- > > From: Eddie Wai > > Date: Wednesday 5 June 2013 7:00 AM > > To: "shyam_i...@dell.com" > > Cc: "open-iscsi@googlegroups.com" , Vikas > > , Lalit Chandiv

Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support

On 6/10/13 10:47 PM, Vikas Chaudhary wrote: -Original Message- From: Eddie Wai Date: Wednesday 5 June 2013 7:00 AM To: "shyam_i...@dell.com" Cc: "open-iscsi@googlegroups.com" , Vikas , Lalit Chandivade , Ravi Anand , Poornima Vonti , Manish Rangankar , Adheer Chandravanshi Subject: R

Re: do discovery through SW transports too

On 6/9/13 9:54 AM, Or Gerlitz wrote: usr]# make Hey, Did you figure this out? Support for that changed. You need to do make from the top level dir, because of dependencies on other stuff. Once that stuff is built you can do make from the usr dir to build just the usr stuff. -- You receiv