RE: patch to discovery.c to still getpathpriorityforpaths with path state of PATH_DOWN

[Dave Wysochanski <dave.wysochanski@redhat.com>]

On Wed, 2006-11-15 at 17:48 -0500, Edward Goggin wrote:
> OK.  I was trying not to have to introduce another
> prio state because that approach just seems prone
> to error.
> 
> I'll give it a try tomorrow.
> 

Ed has a point.

An effect of using the special value approach over the flag is a
potential conflict with the callouts using the same values.  The flag
approach isolates his initialization case better.


> > -----Original Message-----
> > From: Christophe Varoqui [mailto:christophe.varoqui@free.fr] 
> > Sent: Wednesday, November 15, 2006 5:34 PM
> > To: goggin, edward
> > Cc: dave.wysochanski@redhat.com; dm-devel@redhat.com
> > Subject: RE: [dm-devel] patch to discovery.c to still 
> > getpathpriorityforpaths with path state of PATH_DOWN
> > 
> > Le mercredi 15 novembre 2006 à 14:48 -0500, Edward Goggin a écrit :
> > > On Wednesday, November 15, 2006 1:49 AM, Dave Wysochanski wrote
> > > 
> > > > One other thought I had was the notion of a "priority valid" 
> > > > flag (or a
> > > > special priority value) in the path for the case of 
> > > > group_by_prio.  Set
> > > > it to invalid in alloc_path(), then just don't add the path to the
> > > > multipath struct in coalesce_paths() if the priority value 
> > > > was invalid.
> > > > Then over in checkerloop(), add the path to the multipath 
> > map when you
> > > > get a valid priority.
> > > > 
> > > > It is more complicated than that I'm sure (e.g. 
> > checkerloop() assumes
> > > > pp->mpp is non-null in places, etc) but seemed like a half-decent
> > > > approach to at least consider.
> > > > 
> > > > This approach doesn't take into consideration the general 
> > case of a
> > > > change in path priority though.
> > > 
> > > I very much like the first part of your "priority valid" idea
> > > mentioned above.
> > > 
> > > I've enclosed a patch for the first part of your idea.  The patch
> > > should address the concern you had about recalculating priority
> > > for a path when its path state changes from not PATH_DOWN to
> > > PATH_DOWN.  It now only retrieves the priority for PATH_DOWN
> > > paths if the path's priority has never been successfully
> > > retrieved before.
> > > 
> > How about the following, clarifying PRIO values and avoiding the
> > additional "struct path" element ?
> > 
> > Please have a careful look at the 
> > multipath/main.c:update_paths change,
> > because the (!pp->priority) that was there awfully looks like 
> > a bug (as
> > 0 is not a defined prio value).
> > 
> > Regards,
> > cvaroqui
> > 
> > 
> >