[Federated-fs] Corrected formatting for federated-fs

[Touretsky, Gregory]

> -----Original Message-----
> From: Everhart, Craig [mailto:everhart at netapp.com] 
> Sent: Monday, June 18, 2007 10:50 PM
> To: Touretsky, Gregory; Ellard, Daniel; federated-fs at sdsc.edu
> Subject: RE: [Federated-fs] Corrected formatting for federated-fs

> 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.
Ideally, I'd like to see it defined as part of standard - including the
communication protocol between NSDBs. It would allow to mix and match
NSDBs from different vendors. 

>   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.
If NSDB will keep information about both junctions and filesets - it may
provide this functionality.
Every time new junction gets created for some fileset, the relevant NSDB
would be update

> 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.
Basically, I'd like to see an ability to override FSL for specific
junction for some cell. It might be implemented as part of my other
request (below). So that for clients at cell ABC.com, the replica should
be accessed from local cache.
> * 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

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