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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 23 Dec 2003 08:56:13 -0800

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

I don't think that really was the question.  I don't think I've
said that clients should be banned from interrogating this name
service, when it exists and is standardized.  I can't recall 
anyone else saying that either.  I think the question is, what
is the wisest thing for (v4) clients to do and for v4 clients, I
haven't heard anyone give any reason why getting referrals from
the v4 server is not the best strategy.  The big advantage is
that it can be done now and when the repository is standardized,
your work has already been done.

> 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.

Sure.

> 	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.  

Maybe I'm not understanding what you are saying here, but if I am,
I find this kind of disturbing.

If v4 servers are "not restricted to terminal leafs in the tree", I
think you have bit off a whole lot to address in v3, in fact, too much.

So let us consider a v2/v3 server serving up the fs whose global name
is /global/com/sun/eng/nfs/namespace-dev and suppose that it is non-
terminal which I assume means that there is some other server somewhere
else serving a file whose global name is /global/com/sun/eng/nfs/
namespace-dev/v2v3/client.

Now I can see the client or more precisely the mount command getting
information on where /global/com/sun/eng/nfs/namespace-dev and
/global/com/sun/eng/nfs/namespace-dev/v2v3/client are directly
from the namespace service (no bans here), the case of a v2/v3 server 
serving up a non-terminal fs, goes far beyond that.  If someone has 
mounted namespace-dev, how is he to access namespace-dev/v2v3/client/*?
 
>	   Thus clients will have to have a
> 	   mechanism to get into and out of non-NFSv4 servers.

You are now talking about something of such scope that it calls into
question your basic argument that we have to accommodate existing
protocols.

V4 has, a fundamental feature that you can see and cross a mount 
point within the spaces of fs's served by a server and then we are
able to add referral for an fs to that basic structure.  v2/v3
don't have that concept so trying to have a mechanism to get "out
of" such a server seems like it is very much going against the grain.
I also note that many v4 clients have not yet gotten to the point
where they do a "nested mount" to deal with encountering an fs
junction.  I'm having trouble believing that v2/v3 clients will get
this ability anytime soon.

Clearly, there are ways to make this work, given a willingness to
modify v2/v3 clients and servers to use various ancillary protocols
(and I'm suspecting that you will need to do more than simply talk
to a standard namespace, but we'll see).  I think the reality will 
be that such nominally v2/v3 servers will actually constitute new
versions of v2/v3, despite the fact that the OTW format of v2/v3 NFS 
protocol has not changed.

This seems to me like a big diversion of effort from NFS v4, that
will put actual adoption of it even further out.  Also, given this big
a change to v2 and v3 servers and clients, you have the problem of
dealing with the old legacy v2 and v3 and what their role is in this 
new, more complicated world.

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

No prohibitions.

> 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.

As your CIFS example brings out, even though you can't change the 
CIFS protocol, you would have to change the CIFS clients, to access 
this namespace, and I don't know how one does that.  I'm certainly 
not going to ban it, although others might.

And I'd really prefer not to thin about a CIFS fs as a non-termimal
element of a global namespace.  It really makes my head hurt. 

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

---

From: Brent Callaghan <[email-masked]>
Date: Tue, 23 Dec 2003 10:03:34 -0800

> your work has already been done.

It has been suggested that the server is lacking client context
information that might be important in server selection, e.g.
does this client need the filesystem with Linux or Windows executables ?
Or, does this this client need the replica server in the next room
or in Key West ?  Some decisions on filesystem selection are best
made by the client.

> I find this kind of disturbing.

You may be reading too much into this.  My interpretation is simply
that a global namespace that depends on v4 referrals will force
customers to install a network of v4 referral servers to provide
access to their established base of v2/v3 servers.

Seems better to start with the assumption of a version-neutral
(or even protocol-neutral) namespace and add v4 referrals as an
optimization.

	Brent

---

From: David Robinson <[email-masked]>
Date: Wed, 24 Dec 2003 13:53:16 -0600

> mounted namespace-dev, how is he to access namespace-dev/v2v3/client/*?

We have virtually all of this functionalty in our automounter.  We
allow the placement a 'trigger' node on any arbitrary part of
the namespace that will cause a mount to occur when that node
is accessed. If we are working out way through the namespace that
is served by NFSv4, we don't need to add the triggers because the
NFSv4 server will redirect us automatically.  But if some lower
part of the tree is served by an NFSv3 server, we can just
place a trigger node and handle the redirection on the client.
Likewise if we transition off the v3 server back to a v4 server
we can have another trigger node redirect the client. The core
functionality to do this exists in Solaris today, we just don't
provide a very nice mechanism to specify where to place triggers.
Linux/AMD is mostly there as well.

Microsoft's Dfs works in a similar manner, while it does allow the
server to indicate a redirection, the client still looks up in AD
where to go.

My biggest concern is that if we create an NFSv4-only global namespace
it will be a long slow adoption process as customers are slow to
change infrastructure and often don't have control over both sides
of the wire. There may be parts of the 'global' namespace that
will need to be accessed by clients that can't be upgraded to v4,
if we can leverage existing automounters for v3 clients then
we have a nice transition path. Conversely, we may have data
on servers that may stay v3-only for a long time, we want that
data to participate in the global namespace as well.

I don't see a balkanization of the namespace based on access
protocol.

	-David