Subject: Re: [nfsv4] NFSv4.1 & fed-fs

From: Christian Bandulet - Principal Field Technologist <[email-masked]>
Date: Mon, 02 Feb 2009 09:53:40 +0100

Thanks Robert!

so would it be correct say:

1. NFSv4.0 specification provides pseudo FS which stitches together 
several FS on a single(!!!) server forming something like a 
"single-server global namespace"

2. NFSv4.0 also defines fs_location attribute which could be 
theoretically used for referrals. But referrals weren't part of the 
final NFSv4.0 draft

3. NFSv4.1 defines the fs_location_info attribute and mentions referrals 
based on this attribute

4. NFSv4.1 doesn't define how to populate the fs_location_info attribute 
- i.e. providing a list of filesystem locations. i.e. server name 
(eitherDNS domain or IP address) and the path name representing the root 
of the filesystem.

5. future minor version NFSv4.2 (?) will provide fed-fs -  i.e. a 
uniform way to populate fs_location_info using back-end
name service queries (NSDB?) to find the information dynamically.

6. without fed-fs + NSDB the usage of referrals/fs_location_info doesn't 
really make sense....

Thx,
Christian

Robert Thurlow wrote:
> Christian Bandulet - Principal Field Technologist wrote:
>
>> I browsed through the following documents in order to understand the 
>> basic idea of fed-fs:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-01.txt 
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-protocol-00.txt 
>>
>>
>>
>> I understood that fed-fs can stitch together NFSv4 namespaces - i.e. 
>> dynamically and transparently for the clients...
>>
>> After that reading additional questions came up to my mind:
>>
>> - NFSv4.1 can also create a global namespace via "referrals"....
>>  how is the NFSv4.1 fs_location_info attribute which is used for 
>> referrals populated if you don't have a NSDB like fed-fs?
>
> NFSv4.1 does not specify this, so without FedFS you're left
> making something up in a non-standard way.  Our testing at
> places like Connectathon was generally supported by vendors'
> use of new share options to insert referrals data by hand
> on an ad-hoc basis; some have talked about using back-end
> name service queries to find the information dynamically.
> As a result, fs_locations/fs_locations_info are not widely
> implemented and used yet, and we hope FedFS will help.
>
>> - NFSv4.0 has a fs_location attribute but doesn't provide referrals...
>>  what is the purpose of the fs_location attribute in NFSv4.0.  I 
>> thought NFSv4.0 didn't provide a multi-server namespace?
>>  I believe that there were expressions similar like "single-server 
>> namespace" and "pseudo filesystem" related to NFSv4.0 and that 
>> "multi-server     namespace" was introduced only with NFSv4.1.
>
> There's one more part to the history: after NFSv4.0 was done,
> Dave Noveck and Carl Burnett wrote some drafts about how a
> NFS4ERR_MOVED migration event could be repurposed to give the
> client a referral, and worked up some rules for how this should
> be done.  The thought experiments and the implementation experience
> lead to the NFSv4.1 language about referrals.
>
> Rob T

-- 
====================================================================
Christian Bandulet                         Sun Microsystems
Principal Engineer                         Amperestr. 6
Data Management Ambassador                 D-63225 Langen
                                           Germany
                                           Tel.: +49-6103-752-142
                                           (Sun: x65142)
                                           Fax.: +49-6103-752-299

mailto:[email-masked]
http://www.sun.com

===================================================================== 
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering 
===================================================================== 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 2 Feb 2009 09:12:02 -0500

On Mon, Feb 2, 2009 at 3:53 AM, Christian Bandulet - Principal Field
Technologist <[email-masked]> wrote:
> 1. NFSv4.0 specification provides pseudo FS which stitches together several
> FS on a single(!!!) server forming something like a "single-server global
> namespace"

Yes, but that "single server" could be a cluster.  One other purpose of this,
of course, is to make it easy to consolidate the volumes on a server/cluster
into a single mount point.

> 2. NFSv4.0 also defines fs_location attribute which could be theoretically
> used for referrals. But referrals weren't part of the final NFSv4.0 draft

Yes.  But referrals were almost in the 4.0 draft; they just hadn't realized
it yet.

> 3. NFSv4.1 defines the fs_location_info attribute and mentions referrals

Yes.

> 4. NFSv4.1 doesn't define how to populate the fs_location_info attribute -
> i.e. providing a list of filesystem locations. i.e. server name (eitherDNS
> domain or IP address) and the path name representing the root of the
> filesystem.

Yes.

> 5. future minor version NFSv4.2 (?) will provide fed-fs -  i.e. a uniform
> way to populate fs_location_info using back-end

Perhaps.  I can't really speculate about what's going to be in 4.2,
or when 4.2 will appear, but it certainly would be nice to see something
about federated or at least multi-server namespaces.

> 6. without fed-fs + NSDB the usage of referrals/fs_location_info doesn't

I think that's over-stating it.  There have been other proposals for how to
use referrals, and even at least one shipped product (Glamour, from IBM).
I think the fed-fs ideas make *more* sense, but there are other ideas that
make sense as well.

-Dan

---

From: Christian Bandulet - Principal Field Technologist <[email-masked]>
Date: Mon, 02 Feb 2009 15:34:02 +0100

Daniel,

is it really true that you can consolidate several file systems
located  on different servers (i.e. cluster) into a single mount point
with NFSv4.0 pseudo FS? That would mean that one server could become a
proxy for another server....

I thought that pseudo FS was restricted to a file systems within a
single(!) server.....

Christian

Daniel Ellard wrote:

Thanks Robert!

Yes.

Yes.

-Dan

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 2 Feb 2009 09:57:12 -0500

On Mon, Feb 2, 2009 at 9:34 AM, Christian Bandulet - Principal Field
Technologist <[email-masked]> wrote:
> Daniel,
>
> is it really true that you can consolidate several file systems located  on
> different servers (i.e. cluster) into a single mount point with NFSv4.0
> pseudo FS? That would mean that one server could become a proxy for another
> server....
>
> I thought that pseudo FS was restricted to a file systems within a single(!)
> server.....

The definition of "single server" has become fuzzy.  Some kinds of clusters
present themselves as a single NFS service.  Even though there might be
a bunch of hosts working behind the scenes, their number and how
responsibilities
are divided among them are all invisible to the client.

But this isn't NFS.  This is the cluster protocol providing this illusion.  As
far as NFS is concerned, it's one monster server.

-Dan

---

From: Christian Bandulet - Principal Field Technologist <[email-masked]>
Date: Mon, 02 Feb 2009 17:11:35 +0100

Daniel,

please correct me if I am wrong:

NAS clusters presenting themselves as a single NFS server are using
proprietary software... thus the capability to consolidate several file
systems from different NAS cluster nodes is a feature of this software
and not of the NFS protocol (i.e. NFSv4.0 pseudo FS)....

Thus still my question: isn't NFSv4.0 pseudo file system restricted to
a single(!) NFS server although this server might be a NAS cluster?

Thanks for you patience,

Christian

Daniel Ellard wrote:

Daniel,

-Dan

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 2 Feb 2009 11:38:48 -0500

That's an accurate summary.  That's what the "pseudo FS" is in NFS4.0.
 
        Craig

________________________________

	From: Christian Bandulet - Principal Field Technologist
[mailto:[email-masked]] 
	Sent: Monday, February 02, 2009 11:12 AM
	To: Daniel Ellard
	Cc: Robert Thurlow; [email-masked]; [email-masked]
	Subject: Re: [nfsv4] NFSv4.1 & fed-fs

	Daniel,

	NAS clusters presenting themselves as a single NFS server are
using proprietary software... thus the capability to consolidate several
file systems from different NAS cluster nodes is a feature of this
software and not of the NFS protocol (i.e. NFSv4.0 pseudo FS)....
	
	Thus still my question: isn't NFSv4.0 pseudo file system
restricted to a single(!) NFS server although this server might be a NAS
cluster?
	
	Thanks for you patience,
	Christian

	Daniel Ellard wrote: 

		On Mon, Feb 2, 2009 at 9:34 AM, Christian Bandulet -
Principal Field
		Technologist <[email-masked]>
<mailto:[email-masked]>  wrote:

			Daniel,
			
			is it really true that you can consolidate
several file systems located  on
			different servers (i.e. cluster) into a single
mount point with NFSv4.0
			pseudo FS? That would mean that one server could
become a proxy for another
			server....
			
			I thought that pseudo FS was restricted to a
file systems within a single(!)
			server.....

		The definition of "single server" has become fuzzy.
Some kinds of clusters
		present themselves as a single NFS service.  Even though
there might be
		a bunch of hosts working behind the scenes, their number
and how
		responsibilities
		are divided among them are all invisible to the client.
		
		But this isn't NFS.  This is the cluster protocol
providing this illusion.  As
		far as NFS is concerned, it's one monster server.
		
		-Dan

	-- 
	
	                                           Tel.:
+49-6103-752-142
	                                           (Sun: x65142)
	                                           Fax.:
+49-6103-752-299

===================================================================== 
	Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
	Amtsgericht Muenchen: HRB 161028
	Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland
Boemer
	Vorsitzender des Aufsichtsrates: Martin Haering

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 02 Feb 2009 10:00:26 -0700

> (eitherDNS domain or IP address) and the path name representing the root 

I would agree with all of the above.

> name service queries (NSDB?) to find the information dynamically.

One correction: We don't so far know that we have to revise the
current NFSv4.1 client-server protocol in order to fully support
referrals and a global namespace.  If you think of FedFS as a
way to knit servers together, the server-to-server support from
FedFS is what's really needed.  We may see to add attributes
in the NFSv4.2 timeframe to make this work better, but we may
not need to.

> 6. without fed-fs + NSDB the usage of referrals/fs_location_info doesn't 

Probably so.

Rob T

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 2 Feb 2009 11:28:25 -0600

> in the NFSv4.2 timeframe to make this work better, but we may

I view it as a requirement that there be NO change in the
client/server protocol to support referrals/global-namespace.

Spencer

---

From: Daniel Ellard <[email-masked]>
Date: Wed, 4 Feb 2009 16:40:52 -0500

> client/server protocol to support referrals/global-namespace.

I think I agree with your sentiment, but to be persnickety, I would rephrase
it slightly.  Existing clients should continue to work as-is.  No changes
are necessary.

However, there may be additional things that a client (in the role of
an administrator) might be able to say to a server, possibly over a
separate interface.  Whether this is part of NFS or a separate protocol
with its own spec is an interesting question.  I'd like it to be considered
part of NFS, so that admins of heterogeneous federations can administer
those federations in a platform-agnostic way, just as clients can access
the file services in a platform-agnostic way.

-Dan

---

From: Christian Bandulet - Principal Field Technologist <[email-masked]>
Date: Fri, 13 Feb 2009 09:38:58 +0100

Rob et al,

one more question:

- a FedFS consists of federation members
- each federation member consists of a NSDB and a bunch of file servers
- a client connects to a files server in order to access a file
- if the file server hits an "intra-federation" junction it contact the 
NSDB in its federation in order to do FSN to FSL mappings in NSDB using LDAP
- server responds to client with ER_MOVED
- client request fs_location_info from file server....
- client connect to correct file server....

What if the the client requests a file not being hosted in its own 
federation?

Is the a communication/synchronization between federations (i.e. NSDBs)?

Is there something like an "inter-federation" junction?

Thx,
Christian

Robert Thurlow wrote:
>> 3. NFSv4.1 defines the fs_location_info attribute and mentions 
>> referrals based on this attribute
>>
>> 4. NFSv4.1 doesn't define how to populate the fs_location_info 
>> attribute - i.e. providing a list of filesystem locations. i.e. 
>> server name (eitherDNS domain or IP address) and the path name 
>> representing the root of the filesystem.
>
>> 6. without fed-fs + NSDB the usage of referrals/fs_location_info 
>> doesn't really make sense....
>
> Probably so.
>
> Rob T

---

From: Daniel Ellard <[email-masked]>
Date: Fri, 13 Feb 2009 06:27:15 -0500

On Fri, Feb 13, 2009 at 3:38 AM, Christian Bandulet - Principal Field
> - each federation member consists of a NSDB and a bunch of file servers

Usually, but not necessarily.  It's possible for a member to not have any NSDBs
(they delegate this to someone else) or not have any servers (they're just an
NSDB service).  A typical federation member, however, will have at least
one of each.

> - if the file server hits an "intra-federation" junction it contact the NSDB
> in its federation in order to do FSN to FSL mappings in NSDB using LDAP

No, because there's really only one federation (although it may be partitioned
by various mechanisms).

The namespace of NSDB locations is flat and global.  A junction can name any
host as the NSDB.  The federation may be partitioned if the name
cannot be resolved
(either because it is on a private subnet, or doesn't exist) or the
NSDB does not
answer (because it cannot, or because the contacting client lacks the necessary
credentials).  Similarly, even if the NSDB does answer, the host
actually serving
the volume named by the junction may refuse to talk to the client because the
client lacks necessary authorization.

People might think that they are setting up their own private federations, and
this is, in fact, what most people will want to do, but the boundaries of each
private federation is defined by access authorization, not the scope
of junctions.
Just as any web site can have a link on one of its pages that points
to any other
URL a client can resolve, so it is with junctions.  Their scope is DNS/BGP.

-Dan

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 13 Feb 2009 06:59:52 -0500

Perhaps you mean something slightly different.  Let me try in response
to that other meaning. 

> -----Original Message-----
> Sent: Friday, February 13, 2009 3:39 AM
> To: Robert Thurlow
> Cc: [email-masked]; [email-masked]
> Subject: [nfsv4] fed-fs & inter NSDB
> 
> Rob et al,
> 
> one more question:
> 
> - if the file server hits an "intra-federation" junction it 
> contact the NSDB in its federation in order to do FSN to FSL 
> mappings in NSDB using LDAP

[cfe] Your terminology: federation "members" consist of an NSDB and a
bunch of file servers.  In general, several of these will interact to
make up a single federation.
[cfe] If the file server hits an intra-"member" junction it contacts the
NSDB in its member do to the mappings.
[cfe] If the file server hits an inter-"member" junction, it contacts
the NSDB in the other "member" to do those mappings.

> What if the the client requests a file not being hosted in its own 

[cfe] Are you asking about what happens when you request a file outside
your own group-of-file-servers or outside the whole federation of
groups?

> Is there something like an "inter-federation" junction?

[cfe] Here you get into Dan's territory: FedFS doesn't try to define
what happens if you try to cross from one Federation (a collection of
collections of servers) to another.

---

From: James Lentini <[email-masked]>
Date: Fri, 13 Feb 2009 09:37:24 -0500 (EST)

> in its federation in order to do FSN to FSL mappings in NSDB using LDAP

Almost, but there is one important difference.

The junction contains a Fileset Name (FSN) that indicates which NSDB 
should be contacted. The NSDB may or may not be in the same 
administrative domain as the NFS server.

These slides have an example of how this works:

http://www.snia.org/events/storage-developer2008/presentations/wednesday/Jameslentini_fed_fs-rev.pdf

> What if the the client requests a file not being hosted in its own 

A junction (which appears as a directory name, not a file name) can 
point to other members of the federation.

> Is the a communication/synchronization between federations (i.e. 

A federation can have multiple members. If there is coordination 
between two different administrative domains they are considered 
members of the same federation.

> Is there something like an "inter-federation" junction?

No, because if a junction exists the source and target are by 
definition members of the same federation.

> > > several FS on a single(!!!) server forming something like a "single-server
> > > global namespace"
> > > 
> ===================================================================== Sitz der
> Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551
> Kirchheim-Heimstetten

---

From: Christian Bandulet - Principal Field Technologist <[email-masked]>
Date: Fri, 13 Feb 2009 15:43:46 +0100

Craig,

I guess I mixed up the meaning of the term "federation member":

so is it correct:

- a federation has one or more members

- each federation member can consist of zero, one or more files servers

- each federation member can consist of zero or one NSDB

- a file server hitting a junction can use any NSDB in the federation
in order to resolve FSN to FSL mappings

Thus, is the content of all NSDBs in a federation identical (i.e. in
synch)?

If not, what happens if the file server contacts a "wrong" NSDB first -
i.e. one that cannot resolve the FSN to FSL mapping?

Will the file server in this case contact all NSDBs in the federation
sequentially?

Thx,

Christian

Everhart, Craig wrote:

-----Original Message-----

Rob et al,

one more question:

- each federation member consists of a NSDB and a bunch of
file servers

Is the a communication/synchronization between federations
(i.e. NSDBs)?

Thx,
Christian

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 13 Feb 2009 10:03:18 -0500

Hi, Christian,
 
I'm going to make some comments and also hope that James Lentini's
answer fills in some gaps.

	From: Christian Bandulet - Principal Field Technologist
[mailto:[email-masked]] 
	Sent: Friday, February 13, 2009 9:44 AM
	To: Everhart, Craig
	Cc: Robert Thurlow; [email-masked]; [email-masked]
	Subject: fed-fs & inter NSDB

	Craig,

	so is it correct:

	[cfe] Yes.
	 
	- each federation member can consist of zero, one or more files
servers
	 
	[cfe] Probably one or more. 

	[cfe] Each federation member can contain zero or more NSDBs.
There's in general a single service identifier for the NSDB service for
each identifier, at this point a FQDN, which of course could refer to
any of a collection of actual hosts. 
	
	- a file server hitting a junction can use any NSDB in the
federation in order to resolve FSN to FSL mappings
	
	[cfe] No.  As James points out, a Federated junction (an FSN)
contains a reference to an NSDB for some federation member and also some
key to present to that NSDB to resolve the FSL mappings.  The FSN is
composite: it is made up of both the NSDB identifier and the
key-within-NSDB.
	
	Thus, is the content of all NSDBs in a federation identical
(i.e. in synch)?
	
	[cfe] No.  The NSDB services in a single Federation member are
presumed to be in synch, but there's not in general any relationship
among the content of the different members' NSDBs.
	
	If not, what happens if the file server contacts a "wrong" NSDB
first - i.e. one that cannot resolve the FSN to FSL mapping?
	Will the file server in this case contact all NSDBs in the
federation sequentially?
	
	[cfe] If the file server makes use of the content of an NSDB
other than one of the ones specified in the FSN, it is in error.
	A file server might get at that content in a variety of private,
implementation-defined ways, but the content has to be that obtained
ultimately by the NSDB named in the FSN. 
	
	Thx,
	Christian

	
	Everhart, Craig wrote: 

		Perhaps you mean something slightly different.  Let me
try in response
		to that other meaning. 

			-----Original Message-----
			From: Christian Bandulet - Principal Field
Technologist 
			
			Rob et al,
			
			one more question:
			
			- a FedFS consists of federation members
			- each federation member consists of a NSDB and
a bunch of 
			file servers
			- a client connects to a files server in order
to access a file
			- if the file server hits an "intra-federation"
junction it 
			contact the NSDB in its federation in order to
do FSN to FSL 
			mappings in NSDB using LDAP

		[cfe] Your terminology: federation "members" consist of
an NSDB and a
		bunch of file servers.  In general, several of these
will interact to
		make up a single federation.
		[cfe] If the file server hits an intra-"member" junction
it contacts the
		NSDB in its member do to the mappings.
		[cfe] If the file server hits an inter-"member"
junction, it contacts
		the NSDB in the other "member" to do those mappings.

			- server responds to client with ER_MOVED
			- client request fs_location_info from file
server....
			- client connect to correct file server....

			What if the the client requests a file not being
hosted in its own 
			federation?

		[cfe] Are you asking about what happens when you request
a file outside
		your own group-of-file-servers or outside the whole
federation of
		groups?

			Is the a communication/synchronization between
federations 
			(i.e. NSDBs)?
			
			Is there something like an "inter-federation"
junction?

		[cfe] Here you get into Dan's territory: FedFS doesn't
try to define
		what happens if you try to cross from one Federation (a
collection of
		collections of servers) to another.

			Thx,
			Christian

---

From: Christian Bandulet - Principal Field Technologist <[email-masked]>
Date: Fri, 13 Feb 2009 16:53:41 +0100

"A file server might get at that content in a variety of
private, implementation-defined ways, but the content has to be that
obtained ultimately by the NSDB named in the FSN."

So the admin is responsible to put the correct
NSDB location/name into the FSN manually, right?

Christian

Everhart, Craig wrote:

Hi, Christian,

I'm going to make some comments
and also hope that James Lentini's answer fills in some gaps.

From:
Christian Bandulet - Principal Field Technologist
[mailto:[email-masked]]

To: Everhart, Craig

Craig,

so is it correct:

[cfe] Yes.

[cfe] Each federation member can contain zero or
more NSDBs.  There's in general a single service identifier for the
NSDB service for each identifier, at this point a FQDN, which of course
could refer to any of a collection of actual hosts.

[cfe] No.  As James points out, a Federated
junction (an FSN) contains a reference to an NSDB for some federation
member and also some key to present to that NSDB to resolve the FSL
mappings.  The FSN is composite: it is made up of both the NSDB
identifier and the key-within-NSDB.

[cfe] No.  The NSDB services in a single
Federation member are presumed to be in synch, but there's not in
general any relationship among the content of the different members'
NSDBs.

[cfe] If the file server makes use of the
content of an NSDB other than one of the ones specified in the FSN, it
is in error.

A file server might get at that content in a
variety of private, implementation-defined ways, but the content has to
be that obtained ultimately by the NSDB named in the FSN.

Thx,

Christian

Everhart, Craig wrote:

-----Original Message-----

Rob et al,

one more question:

Thx,
Christian

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 13 Feb 2009 11:04:44 -0500

Well, yes; ideally this will be made simple or trivial by the tools, and
the protocols should make it easy as well.
 
        Craig

	From: Christian Bandulet - Principal Field Technologist
[mailto:[email-masked]] 
	Sent: Friday, February 13, 2009 10:54 AM
	To: Everhart, Craig
	Cc: Robert Thurlow; [email-masked]; [email-masked]
	Subject: Re: fed-fs & inter NSDB

	So the admin is responsible to put the correct NSDB
location/name into the FSN manually, right?
	
	Christian

	Everhart, Craig wrote: 

		Hi, Christian,
		 
		I'm going to make some comments and also hope that James
Lentini's answer fills in some gaps.

			From: Christian Bandulet - Principal Field
Technologist [mailto:[email-masked]] 
			Sent: Friday, February 13, 2009 9:44 AM
			To: Everhart, Craig
			Cc: Robert Thurlow; [email-masked];
[email-masked]
			Subject: fed-fs & inter NSDB

			Craig,
			
			I guess I mixed up the meaning of the term
"federation member":
			
			so is it correct:

			[cfe] Yes.
			
			- each federation member can consist of zero,
one or more files servers

			- each federation member can consist of zero or
one NSDB
			
			[cfe] Each federation member can contain zero or
more NSDBs.  There's in general a single service identifier for the NSDB
service for each identifier, at this point a FQDN, which of course could
refer to any of a collection of actual hosts. 
			
			- a file server hitting a junction can use any
NSDB in the federation in order to resolve FSN to FSL mappings

			Thus, is the content of all NSDBs in a
federation identical (i.e. in synch)?

			If not, what happens if the file server contacts
a "wrong" NSDB first - i.e. one that cannot resolve the FSN to FSL
mapping?
			Will the file server in this case contact all
NSDBs in the federation sequentially?

			Thx,
			Christian

			
			Everhart, Craig wrote: 

				Perhaps you mean something slightly
different.  Let me try in response
				to that other meaning. 

				-----Original Message-----
				From: Christian Bandulet - Principal
Field Technologist 
				[mailto:[email-masked]] 
				Sent: Friday, February 13, 2009 3:39 AM
				To: Robert Thurlow
				Cc: [email-masked];
[email-masked]
				Subject: [nfsv4] fed-fs & inter NSDB
				
				Rob et al,
				
				one more question:
				
				- a FedFS consists of federation members
				- each federation member consists of a
NSDB and a bunch of 
				file servers
				- a client connects to a files server in
order to access a file
				- if the file server hits an
"intra-federation" junction it 
				contact the NSDB in its federation in
order to do FSN to FSL 
				mappings in NSDB using LDAP

				[cfe] Your terminology: federation
"members" consist of an NSDB and a
				bunch of file servers.  In general,
several of these will interact to
				make up a single federation.
				[cfe] If the file server hits an
intra-"member" junction it contacts the
				NSDB in its member do to the mappings.
				[cfe] If the file server hits an
inter-"member" junction, it contacts
				the NSDB in the other "member" to do
those mappings.

				- server responds to client with
ER_MOVED
				- client request fs_location_info from
file server....
				- client connect to correct file
server....

				What if the the client requests a file
not being hosted in its own 
				federation?

				[cfe] Are you asking about what happens
when you request a file outside
				your own group-of-file-servers or
outside the whole federation of
				groups?

				Is the a communication/synchronization
between federations 
				(i.e. NSDBs)?
				
				Is there something like an
"inter-federation" junction?

				[cfe] Here you get into Dan's territory:
FedFS doesn't try to define
				what happens if you try to cross from
one Federation (a collection of
				collections of servers) to another.

				Thx,
				Christian

====================================================================
			Christian Bandulet                         Sun
Microsystems
			Principal Engineer
Amperestr. 6
			Data Management Ambassador
D-63225 Langen
	
Germany
			                                           Tel.:
+49-6103-752-142
			                                           (Sun:
x65142)
			                                           Fax.:
+49-6103-752-299

===================================================================== 
			Sitz der Gesellschaft: Sun Microsystems GmbH,
Sonnenallee 1, D-85551 Kirchheim-Heimstetten
			Amtsgericht Muenchen: HRB 161028
			Geschaeftsfuehrer: Thomas Schroeder, Wolfgang
Engels, Dr. Roland Boemer
			Vorsitzender des Aufsichtsrates: Martin Haering 

	--

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 13 Feb 2009 11:18:12 -0500

Just to be clear.  The operation described in the quoted phrase ("A file
server might...") is outside the proposed standard operation.  But the
tooling should make it straightforward to create FSNs with the
appropriate content: very loosely, the admin would indicate a given
filesystem on a given server, and an entry containing that FSL could be
created in the controlling NSDB for that file server--the NSDB for the
federation member of which that file server is a component..  That entry
would be uniquely identified by the pair (some service location
information for that NSDB, a key for that entry).  We call that pair an
FSN.  An admin could store that FSN as the target of a junction in some
second file server in the federation, whether in the same federation
member (file server group) as the first or not.
 
I hope that I haven't just totally trashed your understanding of how
this should work.
 
        Craig

	From: Everhart, Craig 
	Sent: Friday, February 13, 2009 11:05 AM
	To: Christian Bandulet - Principal Field Technologist
	Cc: Robert Thurlow; [email-masked]; [email-masked]
	Subject: Re: [nfsv4] fed-fs & inter NSDB

	Well, yes; ideally this will be made simple or trivial by the
tools, and the protocols should make it easy as well.
	 
	        Craig

		
		
		Christian

		Everhart, Craig wrote: 

			Hi, Christian,
			 
			I'm going to make some comments and also hope
that James Lentini's answer fills in some gaps.

Field Technologist [mailto:[email-masked]] 

				Craig,
				
				I guess I mixed up the meaning of the
term "federation member":
				
				so is it correct:

				[cfe] Yes.
				
				- each federation member can consist of
zero, one or more files servers

				- each federation member can consist of
zero or one NSDB
				
				[cfe] Each federation member can contain
zero or more NSDBs.  There's in general a single service identifier for
the NSDB service for each identifier, at this point a FQDN, which of
course could refer to any of a collection of actual hosts. 
				
				- a file server hitting a junction can
use any NSDB in the federation in order to resolve FSN to FSL mappings
				
				[cfe] No.  As James points out, a
Federated junction (an FSN) contains a reference to an NSDB for some
federation member and also some key to present to that NSDB to resolve
the FSL mappings.  The FSN is composite: it is made up of both the NSDB
identifier and the key-within-NSDB.

				
				If not, what happens if the file server
contacts a "wrong" NSDB first - i.e. one that cannot resolve the FSN to
FSL mapping?
				Will the file server in this case
contact all NSDBs in the federation sequentially?
				
				[cfe] If the file server makes use of
the content of an NSDB other than one of the ones specified in the FSN,
it is in error.
				A file server might get at that content
in a variety of private, implementation-defined ways, but the content
has to be that obtained ultimately by the NSDB named in the FSN. 
				
				Thx,
				Christian

				
				Everhart, Craig wrote: 

				-----Original Message-----
				
				Rob et al,
				
				one more question:

				

				

				

				Thx,
				Christian

				Christian Bandulet
Sun Microsystems
	
Germany
	
Tel.: +49-6103-752-142
	
(Sun: x65142)
	
Fax.: +49-6103-752-299

===================================================================== 
				Sitz der Gesellschaft: Sun Microsystems
GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
				Amtsgericht Muenchen: HRB 161028
				Geschaeftsfuehrer: Thomas Schroeder,
Wolfgang Engels, Dr. Roland Boemer
				Vorsitzender des Aufsichtsrates: Martin
Haering 

		-- 
	
====================================================================
		Christian Bandulet                         Sun
Microsystems
		Principal Engineer                         Amperestr. 6
		Data Management Ambassador                 D-63225
Langen
		                                           Germany
		                                           Tel.:
+49-6103-752-142
		                                           (Sun: x65142)
		                                           Fax.:
+49-6103-752-299

		Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels,
Dr. Roland Boemer