Subject: Re: [nfsv4] Issue46 - extend fs_location_info to support arbitrary string-based attributes

From: Jim Rees <[email-masked]>
Date: Fri, 14 Apr 2006 11:22:15 -0400

The two implementations I'm familiar with are Apollo and afs.  They work
similarly, although the Apollo one is more flexible.

An Apollo deviant link is just a symlink where any part of the link text
that contains "${FOO}" will result cause the name resolver to look for an
environment variable in the current process named FOO.  If it exists, the
value of the ev will be substituted.  This is mostly used to select the
correct binary for a given processor/architecture.  Some consider it a
problem that this scheme uses something that can be set by non-root users.

An afs sysname link is just a symlink.  If the link text is "@sys" it will
be substituted by the current sysname.  The sysname is compiled into the
kernel module but can be reset by root at run time.  It is global to the
computer on which the afs client is running.  The "@sys" actually gets
expanded anywhere, not just in symlinks, but in practice it's only ever seen
in link text.

There is also the Plan 9 scheme but I don't know much about it.

  The size of the moveable part on the NFSv4 namespace is a file system, so
  fs_location_info seemed like the logical place to me to allow clients to
  selected among typed file systems.

That seems wrong to me.  The file system is an administrative unit that
exists so it can be moved around for load balancing or administered for
security.  The type of the file system has nothing to do with the types of
the objects contained within it, at least not for the purposes we're
discussing.  The granularity is much too coarse.  The two concepts are
orthogonal.

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

---

From: Eric Werme USG <[email-masked]>
Date: Fri, 14 Apr 2006 13:13:32 -0400

[On deviant links and whatnot.]

FWIW, Tru64 Unix's clustering does essentially the same thing and I guess
for the same reasons.  While clusters mostly wants a global file space and
does have a shared root, there are cases where we generally want to keep
data on the local member, e.g. daemons that need to run on each member but
don't need to interact.  /usr/tmp is another:

% file /usr/var/tmp
/usr/var/tmp:   symbolic link to ./cluster/members/{memb}/tmp

{memb} gets replaced with member%d where %d is the member's ID # so
the ultimate target is that member's tmp directory:

% ls -l /usr/var/cluster/members
total 40
lrwxr-xr-x   1 root     system         6 Nov 22  2002 member -> {memb}
drwxr-xr-x  23 root     system      8192 May 10  2005 member0
drwxr-xr-x  26 root     system      8192 Jan 27 06:37 member1
drwxr-xr-x  26 root     system      8192 Nov 28 13:29 member2
drwxr-xr-x  25 root     system      8192 Nov 28 13:31 member3
drwxr-xr-x  25 root     system      8192 Nov 28 13:31 member4

(I think the "member" link is for csh and bash users who can't learn to
quote {memb}.)

There's also {implver} which expands to the CPU type, e.g. ev5 or ev6.
I'm not sure if anything uses that.

	-Ric Werme

---

From: Neil Brown <[email-masked]>
Date: Mon, 17 Apr 2006 13:00:35 +1000

> There is also the Plan 9 scheme but I don't know much about it.

Just to extend the taxonomy, I recall that HPUX - in the late 80's at
least, had 'context sensitive files'.

They were really directories with the setuid bit (or some other magic
bit) set.  The directory would contain a number of options with names
like
   bsd4 sysv m68k mips default

Each process would have a 'context' which was a list of similar words
(I never discovered the details of how a context was set).
The first word in the context was the hostname.
The last word was 'default'.
Others would be the processor type with varying degrees of precision,
preferred OS personality (bsd/sysv) and whatever else the sysadmin
wanted.
The rule was that when you lookup a context dependant file, you get
the entry within the directory that appears earliest in the 'context'
for that process.

I don't know how well it worked in practice as we didn't end up buying
HPs (got apollos instead :-).

I have always rejected any requests to put magic symlink translation
into the Linux NFS server.  It just doesn't belong there.

I prefer the approach:
  Context-dependant objects should be symlinks to  /context/objectname
  (or similar), and the client is responsible with populating /context
  (a local filesystem) with whatever is appropriate.

Any one (man or machine) that cannot handle symlinks in 2006 needs a
serious upgrade.

NeilBrown