On Oct 1, 2008, at Oct 1, 2008, 4:55 PM, J. Bruce Fields wrote:
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.
I agree that since lockd generates the cookies, we can be smarter
about how lockd deals with cookies coming back from statd, and I
strongly prefer an approach that treats the opaques as arbitrary
rather than interpreted values.
I think we may need to keep some IPv6 support in lockd for loopback
down calls. On an AF_INET6 listener socket, loopback calls will come
from the IPv6 loopback address, AFAICT, even if they are sent from
user space via the IPv4 loopback address. The kernel's network layer
will map the IPv4 loopback address to the IPv6 loopback address
automatically.
I am working on revising last week's patch set based on your
comments. I plan to repost an updated version of these soon, but I
can leave out the last two or three patches that deal solely with the
mechanics of these NSM-related cookies.
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.
--
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
