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

[Touretsky, Gregory]

> 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.
As I've answered on another thread:
What is the logic behind replica selection? Let's
say, we have 2 networks in the US site, and the 3rd one in Bangalore.
Can we ensure that clients from both networks in the US will always
start from the US replica, and clients in Bangalore will always start
from the Bangalore replica?
Also, in some cases, I'd be interested in something more granular than
subnet. For example, use netgroup membership as a criteria for
mountpoint resolution

> 
> >>* 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.

> 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).
Yes, this is what I mean

> 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.

This may work for decisions based on fileset proximity, but wouldn't
support smarter decisions (such as based on netgroup, etc)