Subject: [nfsv4] Global namespace for v4.1?

From: Jon Haswell <[email-masked]>
Date: Fri, 19 Dec 2003 17:10:34 -0800

David.Robinson wrote :

> If we have standardized the namespace information, then
> it is relatively simple for a smart client to directly
> query it and skip the need to use the server for a
> referral.  This may help environments where there are
> many referrals or the NFS latency is high.

But should we allow clients two methods for obtaining this information ? I
would argue that providing two ways of doing things, unless there is a very
strong reason to do so, just increases complexity and testing. Additionally
when we get into global namespaces with migration and replication we need
to ensure that clients are redirected around the global namespace in sync
with the movements of data, if we allow clients to bypass the server and go
straight to a separate namespace server we have to keep more entities in
sync, and yes it's possible but more complex with more testing required .

I think we should support simple clients who deal only with the NFS server,
keeping their installation and operation simple.  In the case where we have
many referrals, to the point where a server that is not serving data but
only referals is a bottleneck isn't the answer to replicate this server ?
If NFS server latency is high and the server itself isn't the bottleneck
isn't it also reasonable to assume the client to namespace server latency
will also be high, i.e. we are dealing with a client with a poor network
link to the rest of the world (and it would be surprising if the NFS server
or namespace server were on such a poor communication link).

Jon

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Brent Callaghan <[email-masked]>
Date: Sat, 20 Dec 2003 14:34:18 -0800

I also prefer a single method of querying the namespace,
that is client-based (David's option #1).

An important feature of a client-based solution is that
it's accessible to clients that are connecting to existing NFSv2/v3
servers.  The same service could also extend the namespace
to other file access protocols.

A global namespace that's not tied to a specific version of
the NFS protocol is very much easier to deploy in a
customer network with a variety of NFS clients and servers.

Why wait for protocol changes and/or NFSv4 deployment ?
Why not do it now ?

	Brent

---

From: David Robinson <[email-masked]>
Date: Mon, 22 Dec 2003 16:30:15 -0600

To answer the various forms of the question, "Why allow
clients to lookup the global namespace?"

My reasons are as follows, not necessarily in order:

	1) We need to have a global repository for naming
	   information to provide a standard repository and
	   standard repository access method.  Effectively
	   NFS servers will be a client of the repository.
	   NFS clients can equally be clients of the repsoitory.

	2) I would expect zero changes to the NFS client/server
	   protocol.

	3) The global namespace must handle servers that are not
	   NFSv4 and thus cannot refer clients.  Given the adoption
	   rate of customers there will be NFSv3-only servers for a
	   long time and they will not be restricted to terminal
	   leafs in the tree.  Thus clients will have to have a
	   mechanism to get into and out of non-NFSv4 servers.

	4) Automounters are widely deployed today.  Creating a new
	   mechanism that prohibits them from participating in
	   any way will not be readily adopted.

If all the world were to be NFSv4-only I would have a lot more
sympathy to banning access to the naming repository from the
client. But the 'global' namespace will need to be multi-vendor
and multi-protocol (possibly including CIFS) if we are to
meet customer expectations.

	-David