Hi Chuck, On Thursday September 4, chuck.lever@xxxxxxxxxx wrote: > > > > The IP address of that the SM_NOTIFY came from is the most reliable > > thing we have to identify which host just rebooted. We use that to > > find a 'dns_name' when we first MONitor a host, and use that name for > > the file stored in /var/lib/nfs/sm. We then match the source of > > SM_NOTIFY against those file names. > > Honestly, I would have thought exactly the opposite is true. How > would that work with multi-homed peers? Or with peers that might get > their IP addresses via DHCP? The DNS is used specifically to deal with multi-homed peers. We used to just store IP addesses and match on IP addresses. But that doesn't work with multi-homed hosts. The fully qualified DNS name is the closest thing we have to a reliable unique host identifier, so that is what we use. Clients that use DHCP might be a problem if it isn't hooked in to the DNS properly. I don't think there is any really good general solution to that problem. I certainly would trust the monname reported by such a client. The problem here is that STATMON is over-engineered and under-specified. You cannot implement it "correctly". The best we can do is to do our best. And I think that means using DNS names as the primary key. It is at least a well understood primary key. > > Is there any guidance in the Open Group standard on how to match > SM_NOTIFY requests to SM_MON? I had thought it was "use the mon_name, > Luke". I don't know what the Open Group standards say. My vague memory is "not very much" but I could be wrong. However I think that "always use the mon_name" doesn't actually work in practice, so it doesn't really matter if it is a standard or not. > > And normally I would take that approach. In this case, folks want > real IPv6 support yesterday... The cynic in me wonders if this is just so they can tick the box, or if there is a real use case that demands it. Hopefully it is the latter. :-) NeilBrown -- 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
