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

From: Jon Haswell <[email-masked]>
Date: Tue, 23 Dec 2003 23:32:15 -0800

Dave Noveck wrote :

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

Brent Callaghan wrote :

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

Well my reaction is that clients should not be allowed to interrogate the
name service directly. Let me explain why I don't believe forcing the
client to use the NFS V4 protocol is an issue and why I believe it is
advisable to have the client constrained in this manner.

Firstly, unless I have missed something, we haven't yet determined what the
protocol to the namespace server will be. We might choose to use LDAP for
the namespace server and to define a schema for it that we will be
querying, or it might be something else. Whatever it is however the
combination of the protocol+schema will be new and have to be 'installed'.
If an organization is upgrading from v2/v3 to a global namespace I believe
that will be a major transition for them and they will have to install a
set of namespace referral servers, why is it a bigger issue if they talk
NFS V4 as opposed to LDAP+schema ?

Secondly as to why I believe we should have the clients constrained. Once
we have established our global namespace and defined how data migration and
replication is going to work we are going to need management agents that
will migrate and replicate data and manage all the components in the system
to make this seamless and reliable. If we have the clients independantly
contacting the backend namespace server then we have to ensure we keep this
in sync with the data movement occuring between the servers. While it is
not a disaster if clients are going to the wrong server during transitions,
due to skew between the NFS servers and the namespace it is undesirable -
as I write this I expect somebody to be saying, but he is thinking that the
namespace referrel is on the data servers and in big installations that
won't be the case. I agree with this but my point is that I won't to be
able to design smaller more compact systems where the referrels are
happening on the data servers and to be able to rely on clients not going
behind my back).

My final point on this topic is that even if we do define a protocol where
clients are allowed to access a namespace server directly we should have a
way for an NFS server to tell them to stop doing this, either temporarily
or permanently. Hence if the server knows it is going to get out of sync
with the namespace for some period of time, say when it is internally
moving things around in some closely coupled cluster, it can force the
colients to come through it, Perhaps think of using a form of delegation
that allows clients to go to a global namespace, but which can be revoked
by a server.

Jon Haswell
IBM Research

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

---

From: Brent Callaghan <[email-masked]>
Date: Wed, 24 Dec 2003 11:16:09 -0800

> NFS V4 as opposed to LDAP+schema ?

Yes, a new global namespace will have to be installed.  It's easier just
to install it just on the clients - than on both clients and servers.

Keep in mind that name services like LDAP, Active Directory etc are already
widely deployed, have published APIs and libraries, trained admins and nice
administrative tools.  With an NFSv4 based referral service, you'd have to
start from scratch.

> happening on the data servers and to be able to rely on clients not going

I don't understand your reasoning.  Data movement between NFS servers
may not use the NFS protocol at all.  A data movement tool can just
as easily make namespace changes with a back-end namespace server
as it can with a network of NFSv4 referral servers.  As long as the
data movement and namespace update steps are done in the right order,
there needn't be a sync problem.

Keep in mind that the market doesn't sell "NFS Servers" - they're
muli-protocol NAS servers that handle a variety of file access
protocols: most notably NFS v2/v3, CIFS, AFP, Netware, FTP, HTTP etc
Any cross server movement of data must take into account all these
other access methods - not just NFSv4 clients.

> that allows clients to go to a global namespace, but which can be revoked

Again, as long as the data movement steps are done in the right order,
there should be no issue with getting out of sync with the namespace.
The time to move data >> time to update the namespace.

 > <snip>
> I really would like to avoid having to try and represent this type of
> dynamic and client specific location information from an LDAP schema or the
> like and be able to force the clients, at least in this case, to get their
> namespace information from the NFS server directly, even when this NFS
> server cluster is also part of a larger global namespace, i.e. I want to be
> able to use the NFS servers as a filter on the view of the global namespace
> stored in LDAP or wherever.

My guess is that NAS cluster vendors will continue to design for multiple
protocols and assume the dumbest clients.  If you already have a transparent
solution for switching v2/v3 and CIFS clients from node to node, then it's
easier to extend the same solution to v4 clients, rather than build v4 specific
solution - even if it's "better".

I'd expect an NFS cluster to advertise itself, and be administered as a single,
virtual NFS server, i.e. the cluster will likely load balance without making
any changes to the name service or the perceived location of the data.

	Brent