Feature added in 0.4.5-pre2 : now multipathd checkers proactively fail_path upon up -> down transitions. It won't appear on ftp before tomorrow, as I suddenly lost my dev shell at osdl because of a server move (planned, /me stupid) This enhancement request wasn't ignored, just pushed after the "great stabilization" (which is now I guess) Regards, cvaroqui On jeu, 2005-04-28 at 15:45 -0400, goggin, edward wrote: > On Wed, 27 Apr 2005 12:27:32 -0400, "goggin, edward" wrote: > > > Although I know it sounds a bit radical and counter intuitive, > > but I'm not sure of the utility gained in the current multipathing > > implementation by multipathd periodically testing paths which > > are known to be in an active state in the multipath target driver. > > Possibly someone can convince me otherwise. > > ... (added to save space) > > > Furthermore, while the checkloop function reacts immediately > > to a multipathd state transition of failed to active, the code > > appears little interested (other than updating the multipathd > > path state to failed) in the case where the multipathd path > > state changes from active to failed. > > >From the content and volume of the negative feedback to my proposal, > it is clear to me that I did a horrible job presenting my point. It > seems that no one paid any attention to the second paragraph above > nor to the fact that multipathd has NEVER (as far back as 01-04-2005 > anyway) failed path state in the kernel when one of its path tests > failed. I've pushed for this in the past several times on dm-devel, > as far back as February. I stopped pushing when the idea was > rejected/ignored! > > My email yesterday was simply questioning why even test active paths > if we do nothing with the result of the test. > > I was not saying that we shouldn't test active paths. Clearly, this > is a good thing to do and the current code is only a first pass > implementation of what could be done. > > -- > > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel -- christophe varoqui <christophe.varoqui@xxxxxxx>