[dm-devel] patch to discovery.c to still get path priorityforpaths with path state of PATH_DOWN

[Edward Goggin]

On Tuesday, November 14, 2006 9:27 AM, Dave Wysochanski wrote:
> Are you saying that there's no way in the path checker to distinguish
> between this kind of path and a path that is genuinely down?

No, I'm certainly not saying that at all.  I would rather not
complicate matters by adding yet another path state though.

The particular problem I'm trying to fix is that the path group
membership for a multipath map can be incorrectly initially set
up if scsi_id(8) is successful but the paths are all failed.
When the paths return to a ready state, the path group membership
is not corrected by reloading the map -- this only happens if the
paths are removed and later added back.

What do you think of a fix involving changing need_switch_pathgroup()
in multipathd to check and reload a corrected version of the map
in this case?
  
> By "down",
> I mean "fails ioctl" either directly or with an unexpected
> CHECK_CONDITION (this seems to be what PATH_DOWN means in the 
> code today
> for all the path checkers).  Can you return another state in your path
> checker for this type of path/LUN?
> 
> IMO, if at all possible, it would be good to leave 
> "PATH_DOWN" with its
> current meaning and not call the priority callouts for paths in this
> state.  If the priority callouts could obtain priorities without SG_IO
> succeeding, it might make sense, but this is not the case 
> today.  If you
> once had a good priority because you could get a command through, now
> you call it when the path is down it will be replaced with an 
> incorrect
> one.

Yes, good point.  The converse of this statement is indeed what my
patch is trying to prevent.  That is, initially having an incorrect
priority before the path groups are created then having the good or
correct priority calculated only after the path groups are already
created.

> 
> Arguably the states are fuzzy and "types of paths" are mixed in with
> "path states" which leads to the fuzzyness/confusion.  Right 
> now I don't
> have a good enough feel for it to offer clarifying suggestions though
> other than the attached comment patch which tries to clarify 
> the meaning
> of each state as it is in the code today.