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

Ellard, Daniel Daniel.Ellard at netapp.com
Wed Jun 27 08:26:41 PDT 2007


Comments interspersed.

My email client and your email client seem to have different notions of
how to format things so apologies in advance for bad wrapping. 

> -----Original Message-----
> From: Touretsky, Gregory [mailto:gregory.touretsky at intel.com] 
> Sent: Wednesday, June 27, 2007 10:40 AM
> To: Ellard, Daniel; federated-fs at sdsc.edu
> Subject: RE: [Federated-fs] Conf call notes from 6/25/2007
> 
> 
> >> * 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.]
> 
> But how clients would become aware of the existence of such 
> caching appliance? 
> Let's say we have /nfs/dir/junctionA path, which should bring 
> us to the data located at filesetA. FilesetA belongs to cell 
> ABC.com in the US, and clients from the same network would 
> get the data directly. Now, we have clients in Bangalore that 
> require access to the same data. To optimize such access, 
> we've deployed caching appliance (or even simply replicated 
> the data) to some fileset in Bangalore. I want the ability to 
> ensure clients in Bangalore first approach local copy 
> (whether cached or
> replicated) before trying to access the original fileset overseas.

I may be overlooking something here, but it seems like this question
involves deeper issues beyond the namespace.

If the cache contains fileset replicas, then from the point of view of
the federation it's just another fileset server that just happens to be
local, and it shouldn't be treated differently.  The client should
recognize its "closeness" and use it.

If the cache just contains fragments of filesets, then it's not behaving
like a server.  It's a special thing that the client finds out about in
a special way -- no change from the current situation.  Bangalore
clients would all be preconfigured to check the local cache first, and
other clients wouldn't look there (but might look in some other local
cache).

 
> 
> >>* 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.
> 
> Ideally, I'd like to eliminate automounter (whether autofs or 
> am-utils) from the environment, once we get federated-fs 
> implementations. I'd leave the completeness of all conditions 
> to the administrators.
> Conditional mountpoint resolution is very helpful in large 
> environments, which may require network separations due to 
> security reasons or geographical distances. See the 
> US/Bangalore example above - conditional mounts/redirections 
> might be solution for that.

I think we might have misunderstood the original idea, or maybe there's
more than one idea here.

The idea I thought you were bringing up was that different clients might
see different things when they resolve the same name.  For example, when
you resolve /foo/bin you'll see the intel versions of the executables
(assuming you're using an intel box) and if I'm on my old mac and
resolve /foo/bin I'll see the PPC binaries.  We didn't like this, for
the reasons described earlier.  It would be better to have /foo/bin.i386
and /foo/bin.ppc and use the namespace explicitly to give different
things different names.

The idea that you're bringing up here, I think, is that different
clients might see different instances of the same thing when they
resolve the same name.  For example, when I'm in Bangalore I'll get
/foo/bin.ppc from some Bangalore host instead of the server in Boston,
but the only difference would be in the performance.  No matter what FSL
I pick for a given FSN, I'll see the same thing (disregarding
propogation delays, etc).

The question is who decides.  The current model is that the server tells
the client all the FSLs, and the client picks one to use.  This assumes
that the client is intelligent enough to make a good decision: it knows
to use the local cache, or the nearest server, or something else.

The NSDB might try to order the FSLs in the order that it thinks that
the client would choose them, but this could be tricky because this
requires that it knows as much about the clients network path between
the client and each FSL as the client.  (in the case where the client is
accessing via a proxy or a caching appliance, the NSDB might not have a
very good idea about where the client really is, anyway)

-Dan


More information about the Federated-fs mailing list