Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-11-05 Thread Todd Gill
On 09/02/2015 04:48 AM, Hannes Reinecke wrote: > On 09/02/2015 08:39 AM, Christoph Hellwig wrote: >> On Tue, Sep 01, 2015 at 02:57:57PM +0200, Hannes Reinecke wrote: >> >> It might be a good idea to prioritize that. Todd has been asking >> for multipath monitoring APIs and suggested adding D-BUS A

Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-09-23 Thread Ewan Milne
On Tue, 2015-09-22 at 22:15 +0200, Hannes Reinecke wrote: > On 09/22/2015 09:49 PM, Ewan Milne wrote: > > On Thu, 2015-08-27 at 14:41 +0200, Hannes Reinecke wrote: > >> The current ALUA device_handler has two drawbacks: > >> - We're sending a 'SET TARGET PORT GROUP' command to every LUN, > >> dis

Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-09-22 Thread Hannes Reinecke
On 09/22/2015 09:49 PM, Ewan Milne wrote: > On Thu, 2015-08-27 at 14:41 +0200, Hannes Reinecke wrote: >> The current ALUA device_handler has two drawbacks: >> - We're sending a 'SET TARGET PORT GROUP' command to every LUN, >> disregarding the fact that several LUNs might be in a port group >> a

Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-09-22 Thread Ewan Milne
On Thu, 2015-08-27 at 14:41 +0200, Hannes Reinecke wrote: > The current ALUA device_handler has two drawbacks: > - We're sending a 'SET TARGET PORT GROUP' command to every LUN, > disregarding the fact that several LUNs might be in a port group > and will be automatically switched whenever _any_

Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-09-02 Thread Hannes Reinecke
On 09/02/2015 08:39 AM, Christoph Hellwig wrote: > On Tue, Sep 01, 2015 at 02:57:57PM +0200, Hannes Reinecke wrote: >> That is what I'm eventually planning to do. >> My final goal is to move the multipath path monitoring stuff >> into the kernel (via the block device polling mechanism), and sending

Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-09-01 Thread Christoph Hellwig
On Tue, Sep 01, 2015 at 02:57:57PM +0200, Hannes Reinecke wrote: > That is what I'm eventually planning to do. > My final goal is to move the multipath path monitoring stuff > into the kernel (via the block device polling mechanism), and sending > block events for path failure and re-establishment.

Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-09-01 Thread Hannes Reinecke
On 09/01/2015 01:15 PM, Christoph Hellwig wrote: >> +unsigned long expiry; >> +unsigned long interval; >> +struct workqueue_struct *work_q; >> +struct delayed_work rtpg_work; >> +struct delayed_work stpg_work; >> +struct delayed_work qdata_wor

Re: [PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-09-01 Thread Christoph Hellwig
> + unsigned long expiry; > + unsigned long interval; > + struct workqueue_struct *work_q; > + struct delayed_work rtpg_work; > + struct delayed_work stpg_work; > + struct delayed_work qdata_work; > + spinlock_t rtpg_lock; Th

[PATCH 19/23] scsi_dh_alua: Use workqueue for RTPG

2015-08-27 Thread Hannes Reinecke
The current ALUA device_handler has two drawbacks: - We're sending a 'SET TARGET PORT GROUP' command to every LUN, disregarding the fact that several LUNs might be in a port group and will be automatically switched whenever _any_ LUN within that port group receives the command. - Whenever a L