On Wed, Oct 01, 2008 at 04:48:41PM -0400, Chuck Lever wrote: > On Oct 1, 2008, at Oct 1, 2008, 4:33 PM, J. Bruce Fields wrote: >> And from a quick look at nfs-utils/statd/ it certainly looks to me >> like >> it's correctly treating the contents as a totally opaque object. > > That's exactly what happens. The cookie field is generated by the > SM_MON upcall, and passed back by the SM_NOTIFY downcall. OK, that's great. So we can just - Choose whatever contents for the "priv"/cookie field we want to keep the lookup on receipt of SM_NOTIFY easy, and - remove the support for ipv6 on the loopback communication with statd; we don't need it. >> So I think we can put whatever we want in the priv field--an ipv6 >> address, an index into some kernel table, whatever. (The priv field >> shouldn't even have to make sense to a future boot instance--we don't >> need to be notified of previously monitored hosts' reboots any more >> once >> we've rebooted ourselves.) > > Apparently, then, rpc.statd doesn't have enough knowledge to make the > downcall via IPv6 when needed. Everything we need to look up the host > must be encoded into the 16-byte opaque field. > > I'll look into it. Thanks! --b. -- 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
