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

From: Jim Rees <[email-masked]>
Date: Fri, 14 Apr 2006 10:18:30 -0400

But there is no automounter in v4, right?

At Apollo we used to call these things "deviant links".  They are incredibly
useful but, as Trond notes, they really need to be evaluated only by the
client.  The problem is that they exist on the server, in the global name
space, so if they are to be useful at all there has to be universal
agreement on the semantics and on the names.

In afs the names are centrally administered and completely standardized, so
I don't know why they didn't work well at cern.  They do work well at UMich.

I'm not going to argue that v4 should or should not have "deviant links".
But if they are allowed at all, they need to be defined in the rfc.

My own opinion is that they don't belong in fs_location_info.  They should
be a special kind of symlink.  If name space splicing is important it should
be allowed anywhere in the name space.

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

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 14 Apr 2006 10:48:53 -0400

> I don't know why they didn't work well at cern.  They do work well at UMich.

The standardised names in afs were very much the problem: for Linux
machines the standard name as supplied by the default IBM/Transarc (now
OpenAFS) code was constructed using a combination of the processor used,
and the word "linux": ie. i386_linux. That is totally useless for most
purposes if you want to use dynamically linked libraries since their
dependencies tend to require information about the distribution used,
the packages you have installed on your machine, etc.

Then there is the fact that some processors can emulate others. Many of
the 64-bit processors out there are running a mixture of 32-bit and
64-bit applications (sparc64, Power64, x86_64,...). Then there is the
existence of software emulators...

Basically it boils down to: how and why should a filesystem be deciding
which binaries you are capable of running? Why can't you put that
intelligence elsewhere?

Cheers
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Fri, 14 Apr 2006 08:06:29 -0700 (PDT)

> But there is no automounter in v4, right?

We are definitely trying to do better than the automounter. The least
common denominator for automounters is pretty bad, and as a result
many customers faced with mandates from their CIOs to use an
eclectic mix of clients use the least common denominator.

> agreement on the semantics and on the names.

I'm familiar with Pyramid's and Sequent's symlinks that had a single bit
to switch between BSD and System V worlds. What do deviant links look like?
Or instead, what would they look like in NFSv4?

> be allowed anywhere in the name space.

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. fs_locations_info is already allowing
name space splicing along different attributes such as "rank" and "order";

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 14 Apr 2006 11:58:19 -0400

On Fri, 2006-04-14 at 08:06 -0700, Mike Eisler wrote:
> We are definitely trying to do better than the automounter. 

automounters have the advantage that they can be customised to take into
account the local client peculiarities. That cannot be done with either
@sys or your proposal.

> The least

Which is usually a good idea anyway. Setting up a cluster that needs to
support 20 different binary formats is a crime that carries its own
punishment.

AFS' @sys has the further disadvantage that it is a filesystem-specific
hack: use the @sys name in a symlink in AFS, and it will magically be
expanded to some preset name. Do the same on any other filesystem on the
same machine, and watch your application complain about file '@sys' not
found.

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Fri, 14 Apr 2006 12:23:38 -0700 (PDT)

> account the local client peculiarities. That cannot be done with either

"cannot" is a strong term here.

Your main issue with @sys was that it was too limiting. 
All forms of Linux were squeezed into an @sys value of linux_386.
The Solaris automounter has bunch of builtin variables that match one for one
with uname -a output plus the isainfo -n output. So we can support
more variables (note title of Issue46 states "arbitrary").

You mentioned the issue of 64 bit clients that support both
32 bit and 64 bit clients. An specific example of the issue
would be process A being 64 bit and wants to load a 64 bit version of
libmysql, and B being 32 bit and wants to load a 32 bit version of libc.
Let's say that the LDPPTHs for them are both have /usr/local/mysql/lib,
rather than /usr/local/mysql/lib32 and /usr/local/mysql/lib64. While
I think it would be simpler to concede that's a problem
not worth solving which doesn't devalue the propose, it can still
be solved. When the 64 bit process goes to access /usr/local/mysql/lib,
the NFSv4.1 file system would see that the process is 64 bit. It would
try to LOOKUP lib64, and GETFH it and see that it is a referall,
via NFS4ERR_MOVED. It would then do:

  PUTFH, LOOKUP "lib64", GETATTR fs_locations_info

It would looks for the locations that have the attribute named say,
INSTRUCTION_SET_ADDRESS_LENGTH and the content "64". (It would also
look for architecture, OS version, and other attributes). From those locations it
selects one (based on the rank and order data).

So server1:/mysql/linux/2.6/15/RH/FC5/i86/lib64 gets mounted.

(If there were no architecture, OS version, address length, etc. attributes, the
the client would just pick based on rank and order)

Now process B, the 32 bit process goes to access /usr/local/mysql/lib.
While it sees a mount point, the NFSv4 file system notes that what was mounted
depended on INSTRUCTION_SET_ADDRESS_LENGTH, and the INSTRUCTION_SET_ADDRESS_LENGTH
attribute for the process doesn't match what is mounted. Back to fs_locations_info.
Now it mounts server5:/mysql/linux/2.6/15/RH/FC5/i86/lib32 onto
/usr/local/mysql/lib. How is that possible? A small matter of programming.
Solaris once supported XFN, aka Federated Naming, and had support for
pathnames that had "thisuser" as one of their components. /xfn/fys.uio.no/...../thisuser
always referred to the home directory of the effective user of the process,
and two different effective uids could simultaneously use the same pathname, but
see different content. It was just programming. And yes, my proposal would
allow "thisuser".