[dm-devel] [PATCH 3/5] dm-multipath: remove process_queued_ios()

[Hannes Reinecke]

On 02/03/2014 11:26 AM, Junichi Nomura wrote:
> On 01/31/14 23:55, Hannes Reinecke wrote:
>> Problem here is that pg_init_done() is per path, so at face value
>> SCSI_DH_RETRY is per path, too.
>> So from that we should be retrying this path (and this path only).
>> Hence it would be correct to call queue_delayed_work directly.
>>
>> However, typically any pg_init affects _every_ path in the multipath
>> device (active paths become passive and vice versa).
>> Which seems to be the intended usage, as we're checking for
>> pg_init_in_progress prior to invoking queue_delayed_work().
>>
>> But _if_ we assume that, then we only need to send a _single_
>> pg_init, as this will switch all paths. So again, a call to
>> __pg_init_all_paths will not do the correct thing as it'll
>> send activations to _every_ active path.
> 
> Sending activation for every paths was introduced by this:
>   commit e54f77ddda72781ec1c1696b21aabd6a30cbb7c6
>   Author: Chandra Seetharaman <sekharan at us.ibm.com>
>   Date:   Mon Jun 22 10:12:12 2009 +0100
> So if you make change in the logic, you have to check whether the
> change does not break what the above solved.
> 
>> (And, in fact, we're trying really hard in scsi_dh_rdac
>> and scsi_dh_alua to bunch together all the various pg_init
>> requests precisely for the cited reason).
>>
>> So my inclination here would be to treat SCSI_DH_RETRY
>> as _per path_, and retry only this specific path.
>> IE removing the check to pg_init_in_progress and call
>> queue_delayed_work() directly.
>>
>> IMHO this would impose the least restriction on
>> the internal workings of the various device handlers.
>>
>> What do you think?
> 
> I don't have strong opinion either way. But if we do that, more code
> has to be changed, e.g. the management of retry count.
> 
> Removing the unnecessary workqueue has already a benefit.
> It would be nice to focus on that instead of folding in more changes.
> 
Yes, that's what I've figured, too.
So I've just included the changes you suggested without modifying
the current logic.

I've already sent a new patchset, please check if the changes there
are correct.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)