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

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

I disagree.  I believe a universal namespace is a goal worth shooting for.

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

---

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

> I disagree.  I believe a universal namespace is a goal worth shooting for.

Then this means you don't believe in load balancing replicas either. :-)

Symlink driven namespaces: been there, done that, found them lacking.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 14 Apr 2006 14:49:41 -0500

> I disagree.  I believe a universal namespace is a goal worth shooting for.

And what, pray tell, is "non-universal" about what I described?

Your entire namespace is visible in /nfs/<domain>/, including all the
logical variants that clients might want to see, it's just that the
clients have symlinks for "legacy" paths that applications expected from
before the advent of referrals-driven NFSv4 namespaces, and these
symlinks are really just shorthands for the portions of the namespace
that the clients really care about.

Are you supporting Mike's proposal that variable/value pairs be added as
tags for fs_loctions that clients then have to filter?

And what's the difference between that and what I propose, beyond this:
that one proposal requires no protocol changes while the other does?

In both proposals the clients have to select values for the set of
variables in question.  In both proposals the namespace administrator
has to construct a namespace that addresses the needs of the clients.

But one requires no protocol extensions.

Or are you objecting to Mike's proposal also?  If so, what do you
propose instead?

Nico
--