[Federated-fs] Conf call notes from 6/25/2007

[Ellard, Daniel]

Please let me know if I've missed anything, miss-spelled your name, put
words in your mouth, etc.

Attendees:

Paul LeMahieu - EMC/Rainfinity
Renu Tewari, Manoj Naik - IBM Almaden
Sanjoy Chatterjee - Microsoft
Daniel Ellard, Craig Everhart - NetApp
Rob Thurlow - Sun

Someone else beeped in, but didn't identify him/herself.

Notes from the recent ietf draft:

- Why so much whitespace at the bottom of the figures?

	Dan will look into it.

- Are clients involved in resolution?

	No.  Clients aren't even aware where the junctions are.

- We've been assuming that NSDB nodes can be named in some
easily-resolved manner (i.e., using DNS) but this assumption hasn't been
made explicit.

	Related note: Craig Everhart has a IETF draft on using DNS SVR
records for a similar purpose.  It could certainly be used here as well,
but that would need to be stated too.  In the end, we just need to pick
a method.

- What if a server is also a client?  For example, server X exports one
of its local file systems /r/foo as a fileset, accessible somewhere in
the namespace as fileset foo.  But it's also accessible locally, on that
server, as /r/foo/...  If a local process accesses /r/foo/whatever and
that turns out to be a junction to a fileset on some other server, what
should happen?

	The AFS/NDAF way that the junction appears, to the local file
system, as an empty directory.  No magic occurs; the junction doesn't
work if you don't access it via some non-NSDB-aware interface.  (If
local file system implementors decide that they want to make this work,
they are free to stitch together whatever they like -- but they are not
REQUIRED to do so.  The namespace must be accessible via NFS, CIFS, etc,
but need not be accessible via local file access interfaces.)  This was
the consensus of the folks on the call, but one of the homework
assignments for Rob and Dan is to try to come up with a compelling use
case where there must be "local" access to the namespace.  [If you have
any, please send them along!]

Notes regarding discussion of the email that Greg Touretsky (Intel) sent
last week:

* Name space information should be replicated between several NSDB
servers...

	Agreed, but this is a best practice, rather than a requirement.

	At most, NSDB nodes SHOULD be implemented in a fault-tolerant
manner, as a replicated service.  The NSDB has to be robust, or the
whole system flies off the rails.  But we do not think that the
mechanism for providing robustness should be specified here.  Requiring
that NSDB nodes pair up with other NSDB nodes, for example, is somewhat
contrary to the notion of federation we have been using.

* Support several junctions for the same fileset ...

	We weren't exactly sure what this meant, but talked about
several possibilities.

	a) can one fileset be represented by more than one FSN?

		NO.

	b) can there be more than one junction that refers to the same
fileset?

		YES.  There's some burden on the client to make this
work.
		The client must be smart enough so that ".." works.

* Need namespace awareness of data caching appliances...

	The consensus was no.  Should be the other way around.  The
clients should communicate with the caching appliance as usual and the
appliance navigates the namespace on their behalf.  In the current
reqts, it's possible that if a caching appliance makes a copy of an
entire fileset, it can inform the NSDB node responsible for that fileset
that it has a copy, and other clients could find it there, but that's
not the usual mode of operation for these caches.  [If we've understood
the idea, please guide us.]

* Need reverse mapping possibility - find junction(s) based on FSN.

	Could do this with annotations, sort of.  The difficulty is that
junctions can be manipulated with local fs tools -- moved, renamed,
deleted.  It would take some plumbing to ensure that anything that
modified the path to a junction updated the NSDB.  For example, if I
have a junction at /x/y/z/a/b/c/d/e and I rename /x to /xx, then I've
got to update the record for e.  That could potentially be a lot of
book-keeping.

	We didn't come up with a compelling need for this.  If someone
has a compelling use case, please present it.  Otherwise we're going to
not do this.

* Support various FSLs for the same junction, based on switched
conditions.

	Consensus was no.  Sounds like it could be handy in some cases,
but overloading the namespace violates one of our core goals: two
observers of the same item in the namespace should see (disregarding
temporary inconsistencies) the same thing.

	A secondary consideration is the difficulty in framing the
"conditions".  It seems like these could be open-ended.  Right now, the
resolution is done completely by the server and the client is only
presented with the result.  If there are client-based conditions driving
the resolution, then the protocol has an extra step -- the server will
respond to a client accessing a junction with another query: "Dear
client, before I can show you the proper instance of the object you just
requested, I have to ask you some questions about yourself."  This makes
caching difficult (or impossible, if the answers aren't deterministic)
especially for caching appliances that are trying to demultiplex
accesses from many clients.

	If there was a fixed set of conditions, that could all be
determined once and for all at mount time (for example) then this might
be tractable, but the general case seems very hard -- and if you agree
with the first bullet, undesireable to solve anyway.

	Again, if there's a compelling use case, let's hash it out.

* Add interface extensions for troubleshooting and debugging ...

	We all agreed that this was a good point, and should be added to
the requirements as a line item.  But without a protocol spec, we can
only require this in an abstract manner -- but putting it in the reqts
means that reviewers of that spec won't overlook it.

* An ability to list orphan filesets (without junctions)

	There were two ways to interpret this.  Globally, this is
probably intractable (i.e., asking one NSDB node whether there are any
orphan filesets anywhere -- impossible, because the NSDB nodes might not
even know about each other, much less know what each other knows).
Locally it's difficult and seems to reduce to the reverse-mapping
problem.  Similarly, if admins are careful and use the tools required by
the spec, then they can accomplish this.  But fool-proofing this
requires baking it into the local file systems, and this is something
we've shied away from requiring everywhere else.

* Support for RO/RW mounts within the namespace. ...

	We didn't completely resolve the tradeoff here between adding a
new kind of expressiveness to a pathname and exposing junction points
within pathnames.  (It was also unclear whether this could be done
without baking it in...)

	If we add the intelligence to treat .../.foo differently than
.../foo, then this still only works with junctions.  We've tried hard to
hide junctions from the apps (the whole goal of the namespace is to hide
the details!) and now we're pushing responsibility out the clients to
keep track of what dirs are really junctions, and decide what to do
about them.

	The nesting of junctions was also an issue: for example, if foo
and qux represent junctions, and if I access

		/foo/bar/.qux/baz

	Do a I get a writable baz?  Or did I need to say

		/.foo/.bar/.qux/baz

	to get a writable baz?

	Feeling on the call was that this expressiveness was not worth
the cost.

-Dan