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

[Junichi Nomura]

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.

-- 
Jun'ichi Nomura, NEC Corporation