[Federated-fs] Corrected formatting for federated-fs

[Everhart, Craig]

Hi, Gregory.  Thanks for the detailed comments; you've covered a lot of
ground here.

You raise several interesting points.  I think some of them would apply
to how one would implement a set of requirements, e.g. the replication
of NSDB servers.  As to mapping FSNs back to junction(s), I'm a little
curious about how that would work--what agent you imagine would be
responsible for maintaining that information.  I understand the desire
to have the functionality from the management point of view.

What I'm most curious about is the relationship between namespace
awareness and data caches; there's definitely a relationship there.  I
understand that you're proposing an effect that you'd like to see, but
I'd be curious about your thoughts on what requirements that might
produce, and maybe some more musing about how you'd be able to hook in a
client-edge cache.

		Craig

> -----Original Message-----
> From: Touretsky, Gregory [mailto:gregory.touretsky at intel.com] 
> Sent: Sunday, June 17, 2007 1:50 AM
> To: Ellard, Daniel; federated-fs at sdsc.edu
> Subject: Re: [Federated-fs] Corrected formatting for federated-fs
> 
> Some comments after reading the draft. If needed, I might 
> join the next meeting and talk about them.
> 
> 1. Namespace proper:
> * Name space information should be replicated between several 
> NSDB servers for redundancy / load balancing
> * Support several junctions for the same fileset - probably 
> covered at R3.a bullet
> * Need namespace awareness of data caching appliances 
> (WAFS-like caches, NetApp FlexCache, etc. ). Something like - 
> for junction Y, at foreign cell ABC.com, mount local cache 
> instead of FSL at the original site.
> Might be an overriding option for administrator at cell 
> ABC.com - as cache might not be known to the admins at original site.
> * Need reverse mapping possibility - find junction[s] based 
> on FSN. This was always a missing piece in AFS days, although 
> was resolved with in-house tools.
> * Support various FSLs for the same junction, based on 
> switched conditions (example: for clients in subnet X, mount 
> FSL1. For clients in netgroup Y, mount FSL2. For all others, 
> mount FSL3). Theoretically, these FSLs might have different 
> export options. Might be an extension for replicas mechanism
> * Add interface extensions for troubleshooting and debugging 
> (report number of accesses per replica, number of clients per 
> NSDB server, etc)
> * An abilitty to list orphan filesets (without junctions)
> * Support for RO/RW mounts within the namespace. Example: AFS 
> notion of /afs/@cell/.rwmount vs /afs/@cell/romount
> 
> 2. Wider ideas - not necessary part of name space:
> * Need some readiness for HSM - 1. # of accesses to fileset 
> in the last day/week - similar to AFS; 2. Dump (aka vos dump) 
> capabilities to ensure fast, reliable backup
> * UID/GID mapping between cells
> 
> Gregory Touretsky
> Intel IT - Platform Capabilities Engineering Storage and Data 
> Sharing solutions architect gregory.touretsky AT intel.com
> (+) 972-4-865-6377, Fax: 04-865-5999
> iNET: 465-6377, M/S: IDC10-2.3
>  
> 
> -----Original Message-----
> From: federated-fs-bounces at sdsc.edu
> [mailto:federated-fs-bounces at sdsc.edu] On Behalf Of Daniel Ellard
> Sent: Monday, June 11, 2007 11:06 PM
> To: federated-fs at sdsc.edu
> Subject: [Federated-fs] Corrected formatting for federated-fs
> 
> 
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: federated-fs-04.txt
> Type: application/octet-stream
> Size: 55814 bytes
> Desc: not available
> Url :
> https://lists.sdsc.edu/pipermail/federated-fs/attachments/2007
> 0611/aa774
> be9/federated-fs-04.txt 
>