On Fri, May 2, 2008 at 6:33 PM, Wendy Cheng <s.wendy.cheng@xxxxxxxxx> wrote: > > So this basically makes it a users problem, I don't > > like it. Statd's standard notifications are just fine and > > I don't want to have anything to do with the process. > > It should work as is, out of the box, without writing > > separate programs to handle stuff that statd doesn't > > do. > > > I think you mis-understand our approach. With our patch, you do *not* need > to do anything if you have only one single (floating) interface to do nfs > export (and you can have the machine configured to use other hostname). The > statd's "my_name" is correctly filled (from kernel by our patch) - it is no > longer bound to 127.0.0.1. What happens when it fails over to node that has different name? Mon_name in NOTIFY changes while address it's coming from does not. Which one should client believe - the address or the name? But OK, I probably need to dig out the patch to have a look. > > One specific segment is just enough for us. > > I know .. but there *are* users and live systems *today* that have multiple > nfs interfaces. For big-fat server, I normally saw 4. I'm still a bit confused - does your patch make it sure that all the extra N+1 IP addresses in the node have nothing to do with NFS? If not, these still seem like two different use cases, ie. making the service tightly bound to one service address instead of making it work right with many. -- // Janne -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
