Trond Myklebust wrote:
On Tue, 2009-08-25 at 14:39 -0400, Trond Myklebust wrote:
On Tue, 2009-08-25 at 13:17 -0500, Tom Haynes wrote:
Trond Myklebust wrote:
On Tue, 2009-08-25 at 11:49 -0500, Tom Haynes wrote:
With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
support the autonegotiation
as defined in the protocol.
We just went through a regression with this algorithm.
NFSv4 also allows the server to change the list of supported security
flavours on the fly at any point in the namespace, and at any time. How
does OpenSolaris currently deal with this?
The client gets a WRONGSEC and then initiates auto-negotiation.
Right, but are there any limits to that?
Will it, for instance, allow process 1 to continue using auth_sys, while
process 2 switches to using krb5 on the same file?
From *reading* the code, I think process 1 is fat, dumb, and happy
until it tries an
action which generates a WRONGSEC. At that point it will have to negotiate.
Should it recover in the case where the administrator suddenly removes
krb5 from the list, and replaces it with krb5i on all subdirectories
of ../../.. relative to your current working directory?
Sorry. Let me be more specific...
Say you have
/foo sec=krb5,rw
and the administrator adds a new rule
/foo/bar sec=krb5i,rw
Will your autonegotiator be able to recover processes that are working
in /foo/bar/... without disturbing those working in /foo/baz/... ?
I'll let someone who knows the client give the real response, but
consider two
threads, one in /foo/baz and one in /foo/bar.
The one in /foo/baz will never get a WRONGSEC.
The one in /foo/bar may never get one either - depending on the server
implementation.
i.e., the server has probably put the FSID in the FH. The client is
handing back
what is probably a non-volatile FH and the server has to honor it. And
the server
may have no clue that the FH is under a new mount point.
What happens if the client redrives a LOOKUP of the directory entry? It
should
discover that the FHs no longer match and do some sort of recovery.
Cheers
Trond
Sounds like a great thing to test at the next BAT. :->
--
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
