Subject: [nfsv4] fs_locations_info and non-uniform namespace requirement

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 29 Jun 2006 11:42:22 -0400

Typically requirements for global namespace specify a requirement for
uniform namespace.  This usually generates pushback in the form of some
sort of requirement for exceptions and thus a non-uniform namespace.  I
take this to be the basic content of what is behind issue 46.  The
purpose of this note is to describe the problems with the form that the
requirement takes in Mike's proposal and suggest some alternatives that
I think are better while still meeting the high-level requirement.
 
The prototypical example of the non-uniform namespace requirement
someone who says "I want /usr/bin on each machine to reflect the cpu
type and possibly other things such as os, release" which seems
reasonable enough.
 
The problem is Mike's suggested method which is as I understand it, that
we would consider all the possible targets for /usr/bin within the
organization's namespace as, in some sense, replicas of each other
(since all will answer to the name /usr/bin despite their different
contents).  Each such "replica" would contain opaque-to-the-server
string attributes such as CPU, OS, RELEASE and the client would then
look at all of the replicas and then select one based on his choices for
those attributes plus the normal priority selection rules for that
subset.
 
So there seem to be a number of problems with this approach:

	First this may force fs_location_info arrays to be enormous.  An
organization may have a very large number of possible sets of data that
might serve as a valid /usr/bin for some machine.  Further many of those
may have sets of replicas (real replicas), so that the total number of
entries that would be sent for the client to scan through to do his
selection could be very large.  Most of the data that the client
receives will not be at all relevant to what it wants, which suggests to
me that making these things replica attributes is not the right way to
go here.
	 
	These are not really replicas.  I know that we anticipate
replicas that might have different fileid's or might be at different
stages of update propagation, but simply tying multiple file systems
together and considering them replicas simply because they have the same
sort of purpose is stretching the concept way too far.  
	 
	By doing it this way, you deprive many things that should be
nameable within the global namespace of any global name.  That is,
/usr/bin has replicas such as "server12a:
/binaries/solaris10/usr/bin/x86-64" and
"server19x:/binaries/solaris10/usr/bin/sparc" but neither of those have
a name in the global namespace or rather they both have the same name in
the global namespace, /usr/bin.  So if I'm creating an image and I want
a particular set of binaries, they aren't in the global name.  If I copy
/usr/bin what is copied will depend on the machine that the copy is
running on.  Not good.  I'm forced to do a separate mount that's quite
at cross purposes with the whole idea of a global namespace.

So my alternative is to observe that what you really want to do in these
cases is map certain names like /usr/bin to a named set of replicas
based on some attribute that the server knows. So rather than have
attribute selection be the basis of the mapping paradigm, I think name
substitution is a simpler and more straightforward approach in that it
avoids massive pseudo-replica sets and naturally gives rise to names
within the global namespace for every set of replicas that you might
need to get to.  
 
So what I'm proposing is that we have a bit in a location-info entry
that makes the resulting name subject to substituion based on string
attributes such as the ones Mike was talking about.  You would define
some character or set of characters (e.g. "$$$" ) as introducing an
attribute so that the referral for /usr/bin would be
some-server:/binaries/$$$os/$$$cpu.  The client would then look at the
result, implement the substituion for its attributes and come up with
some-server/binaries/solaris10/x86-64 or something like that.  My
expectation is that in most cases that would involve a further referral
with the fs_locations_info at that point being referral to a set of
replicas, each of which was identical, to allow for failover.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4