On Oct 1, 2008, at Oct 1, 2008, 4:33 PM, J. Bruce Fields wrote:
On Wed, Oct 01, 2008 at 04:08:39PM -0400, bfields wrote:
On Wed, Oct 01, 2008 at 03:40:05PM -0400, Chuck Lever wrote:
On Oct 1, 2008, at Oct 1, 2008, 2:18 PM, J. Bruce Fields wrote:
On Wed, Oct 01, 2008 at 12:17:02PM -0400, Chuck Lever wrote:
On Sep 26, 2008, at Sep 26, 2008, 7:09 PM, J. Bruce Fields wrote:
On Wed, Sep 17, 2008 at 11:18:11AM -0500, Chuck Lever wrote:
The XDR decoders for the NSM NOTIFY procedure should construct a
full
socket address and store it in the nlm_reboot structure. In
addition
to being able to store larger addresses, this means upper layer
routines get an address family tag so they can distinguish
between
AF_INET and AF_INET6 addresses.
This also keeps potentially large socket addresses off the stack
and
instead in dynamically allocated storage.
So one way to think of this would be that you're extending the
kernel<->statd interface by using the address family of statd's
notify
call to communicate the address family of the host that rebooted.
Do I have that right?
For statd, we're using the same technique that we used when
constructing
the source address in nlmsvc_lookup_host(). There's no family tag
associated with the address because the 16-byte opaque in the on-
the-wire
format has room only for the sin6_addr part of the address.
OK. It seems a bit tricky, but I can't see why it doesn't work.
Right. I couldn't think of something simpler.
rpc.statd has to continue to work with legacy kernels where the
first 4
bytes of the opaque are a 32-bit sin_addr field and the following 12
bytes are zero.
Wait a minute, there's something not right there: rpc.statd shouldn't
interpret the contents of the opaque field at all, should it?
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.
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.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
