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

[Everhart, Craig]

> From: Touretsky, Gregory [mailto:gregory.touretsky at intel.com] 
> >> * 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.

Why not publish the Bangalore site as a replica of the fileset, adding
an FSL?

> >>* 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 conditional resolution here seems a little scary for this
purpose; why can't the client choose which replica is nearest?

		Craig