> > Discussing this issue with Erik this morning, we came up with a proposal > > that has similar effect but with a lot less risk: in.mpathd could simply > > ignore requests to delete targets from an interface associated with a > > failed group, and continue to probe the existing target set (possibly > > expanded target set if new targets are added). When an interface in the > > group repairs, it could then rebuild the target list based on the latest > > routing table. I prototyped this (literally a one line change) and it > > "seems" to work. > > What do you do when an interface repairs and you look in the routing > table and you don't find any targets?
You'd end up back in multicast mode. If no multicast targets were found, the interface would still be considered running (since that was its last state before the targets vanished). Alternatively, if targets answered, in.mpathd would end up using them until the routes were restored. Either way, it'd be a little awkward but not pathological. > The reason I'm asking is the if things are down for a while the routing > daemon will have deleted all routes out that interface, and after a > repair it will take a while for the routing daemon to rediscover which > routes to add to the kernel. -- meem
