Subject: [nfsv4] Last call for "Requirements for Federated File Systems" (end May 20th)

From: Spencer Shepler <[email-masked]>
Date: Mon, 4 May 2009 22:45:52 -0500

We are starting the working group last call for
"Requirements for Federated File Systems"
which is located here:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-02.txt

The last call will end on May 20th.

The document is slated as an Informational RFC.

Please take these two weeks to review the document and bring comments
to the WG alias.

As a reminder, it is best to have both statements of support of the work
along with comments for change in the current document.

Finally, this is a requirements document, it is important for the
working group to have clarity in these requirements in support
of the final protocol work.

Spencer

---

From: James Lentini <[email-masked]>
Date: Thu, 7 May 2009 12:49:40 -0400 (EDT)

At the risk of stating the obvious, I'll voice my support for this 
document. These requirements are the product of careful review by 
representatives from several NFS vendors.

-james

--
James Lentini | NetApp | 781-768-5359 | [email-masked]

---

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 10 May 2009 15:53:02 -0400

The only thing I saw was on nit-pick in the fifth paragraph in section 2
(Overview).

>  The servers direct clients to the proper locations by existing
>  mechanisms (e.g. the referrals mechanism within [RFC3530] and
>  [NFSv4.1]).  Updates to the locations make it possible to support
>  migration and replication of physical filesystems that comprise the
>  namespace, in a way that is transparent to filesystem clients.

Since the clients get MOVED errors and different FS_LOCATIONS values and
have to acting on them, migration and the failover part of replication
are not transparent to the clients themselves.  The features do allow
implementations to be transparent to the applications that are using the
clients and I think that is what is meant and should be said.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 11:46 PM
To: [email-masked]
Subject: [nfsv4] Last call for "Requirements for Federated File
Systems"(end May 20th)

We are starting the working group last call for "Requirements for
Federated File Systems"
which is located here:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-
02.txt

Please take these two weeks to review the document and bring comments to
the WG alias.

Finally, this is a requirements document, it is important for the
working group to have clarity in these requirements in support of the
final protocol work.

Spencer

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

---

From: James Lentini <[email-masked]>
Date: Mon, 11 May 2009 09:31:53 -0400 (EDT)

That is correct. The text is referring to the clients of a filesystem, 
aka applications. I agree that replacing "filesystem clients" with 
"filesystem applications" would clarify the text.

-james

---

From: Renu Tewari <[email-masked]>
Date: Mon, 11 May 2009 12:07:08 -0700

Adding another voice of support for this document. The requirements have
been vetted for a while now by most of the regular participants and are
tailored to broadly address the needs of  most vendors and their customers.

replacing filesystem clients" with "filesystem applications" would
definitely clarify the text!

renu

============
Renu Tewari, Ph.D.
Research Staff Member
Networked Filesystems
IBM Almaden Research

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 11 May 2009 15:17:58 -0400

I also support this document (which should be no surprise...).

-Dan

On Mon, May 11, 2009 at 3:07 PM, Renu Tewari <[email-masked]> wrote:
> been vetted for a while now
> by most of the regular participants and are tailored to broadly address the
> needs of  most vendors and their customers.

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 11 May 2009 18:12:14 -0400

+1 

> From: Daniel Ellard [mailto:[email-masked]] 
> Sent: Monday, May 11, 2009 3:18 PM
> To: [email-masked]
> Subject: Re: [nfsv4] Last call for "Requirements for 
> Federated FileSystems"(end May 20th)
> 
> > Adding another voice of support for this document. The requirements 
> > have been vetted for a while now by most of the regular 
> participants 
> > and are tailored to broadly address the needs of  most vendors and 
> > their customers.
> >> That is correct. The text is referring to the clients of a 
> >> filesystem, aka applications. I agree that replacing "filesystem 
> >> clients" with "filesystem applications" would clarify the text.
> >>
> >> -james
> >>
> >> > The only thing I saw was on nit-pick in the fifth paragraph in 
> >> > section 2 (Overview).
> >> >
> >> > >  migration and replication of physical filesystems 
> that comprise 
> >> > > the
> >> > Since the clients get MOVED errors and different FS_LOCATIONS 
> >> > values and have to acting on them, migration and the 
> failover part 
> >> > of replication are not transparent to the clients 
> themselves.  The 
> >> > features do allow implementations to be transparent to the 
> >> > applications that are using the clients and I think that 
> is what is meant and should be said.
> >> >
> >> >
> >> > Please take these two weeks to review the document and bring 
> >> > comments to the WG alias.
> >> >
> >> > As a reminder, it is best to have both statements of 
> support of the 
> >> > work along with comments for change in the current document.
> >> >
> >> > working group to have clarity in these requirements in 
> support of 
> >> > the final protocol work.
> >> >
> >> > Spencer
> >> >
> >> >

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 11 May 2009 16:26:52 -0600

> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-02.txt 

I support the work, and believe the requirements to be generally
correct and useful.  They have had some good discussion over time
among the FedFS call participants.

I have one change to request in Section 4.3 of the document:

Junction creation, as described by the example, sounds odd to me.
The example makes it appear that you have to get the FSN from a
fileserver for some reason, whereas I expect that the FSN will
generally be well-known.  I'd like to see the example simplified
here, e.g.:

Given a local path on a file server and an FSN, create a junction
from the local path to the FSN.
...
    1.  Contact the given file server with the given local path and FSN

    2.  The server will insert the junction to the FSN, at the given
        path, into the local filesystem.

Rob T

---

From: Renu Tewari <[email-masked]>
Date: Mon, 11 May 2009 17:33:50 -0700

You raise a valid point. In fact the server hosting a fileset need not know
the FSN of that fileset. The FSN information is stored in the NSDB.
>From the example standpoint we need not elaborate on how the target FSN is
determined in order to create a junction.
So a fileserver, given a target FSN and a local path, can create a junction
at the  given path and associate it with the target FSN.

renu

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 12 May 2009 09:49:25 -0400

Hm.  The intuition I have is different: FSNs are not particularly
memorable.  This doesn't keep them from being well-known, but I expect
that they will need to be allocated from some identifier generator when
a "fileset" is created, as a handle for the fileset as opposed to a
handle or access method for any of its representatives.

That's why I believe that the Section 4.3 example is written in such a
way as to expect that the FSN must be learned by the admin agent, as
opposed to being known to the administrator.  And every host fileserver
is posited to know the FSN for any of its filesets.

		Craig

> From: Robert Thurlow [mailto:[email-masked]] 
> Sent: Monday, May 11, 2009 6:27 PM
> To: Spencer Shepler
> Cc: [email-masked]
> Federated File Systems" (end May 20th)
> 
> Spencer Shepler wrote:
> > 
> I support the work, and believe the requirements to be 
> generally correct and useful.  They have had some good 
> discussion over time among the FedFS call participants.
> 
> The example makes it appear that you have to get the FSN from 
> a fileserver for some reason, whereas I expect that the FSN 
> will generally be well-known.  I'd like to see the example 
> simplified here, e.g.:
> 
> Given a local path on a file server and an FSN, create a 
> junction from the local path to the FSN.
> ...

---

From: James Lentini <[email-masked]>
Date: Tue, 12 May 2009 11:40:14 -0400 (EDT)

As the sentence at the top of page 11 states:

 There are many possible variations to this procedure, ...

The example is describing one way a junction could be created, but 
there are others. As Craig notes, the example is describing the case 
where the FSN is not well known to the administrator. Alternatively, 
the administrator could already know the FSN, which is the case I 
think Rob and Renu have in mind.

I agree that this should be clarified in the text.

I'd propose re-wording section 4.3 as follows:

---

   Given a local path, a remote export and a path relative to that
   export, an administrator can create a junction from the local path 
   to the path within the remote export.

   There are many possible variations to this procedure, depending on
   how the junctions are represented and how the information necessary
   to perform resolution is represented by the server.

   Steps 1 and 2 are the only step that uses the federation 
   interfaces.  The remaining step uses platform-specific 
   interfaces.

   To create a junction from server X to server Y:

   1.  The administrator MAY contact server Y, which hosts the remote 
       export, and ask for the FSN of the target fileset, given its 
       path relative to that export. Alternatively, the administrator 
       MAY known the FSN a priori.

   2.  The administrator requests server X to create a junction at the 
       given path to the FSN of the target fileset on server Y.

   3.  Server X inserts the junction to the FSN, at the given 
       path, into its local filesystem.

---

---

From: Renu Tewari <[email-masked]>
Date: Tue, 12 May 2009 09:18:20 -0700

It is true that FSNs aren't memorable  But server Y need not know the FSN of
the filesetit is hosting. That mapping may just be in the NSDB.  In that
case server Y will need to contact some NSDB (does it know which one) to
find out the FSN.
I am not sure if the  current admin protocol includes this interface?

renu

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 12 May 2009 12:49:58 -0400

Well, that's the rub.  The FSN needs to be unique within the NSDB, for
sure.  And a junction needs to hold an FSN in order to make the correct
referral (via the NSDB) to the fileserver client.
 
It's a bit of chicken-and-egg, though; once a fileset is made to exist
as a possible referral target, presumably it's being added to the NSDB
as an FSL for some FSN.  While it's not strictly required for the target
host fileserver (Y) to know the FSN for the filesets that it's hosting,
ideally there is some memory for the FSN somewhere in the system.
Assuming that the FSN isn't something that the admin remembers by heart
(at least not in all cases), I guess I was positing that the target
would know the FSN.  This lets the admin not have to remember all the
FSNs in their installation.
 
The alternative answer, I think, is to search the NSDB in a way that
Renu mentions.  Is this as simple as asking an NSDB for an FSN that
matches an FSL?  Is this specified?  And how is the FSL canonicalized
for the search--are host names used, perhaps case-folded, or are one or
more host numeric addresses given?
 
In any case, some mechanism is required...
 
        Craig

________________________________

	From: Renu Tewari [mailto:[email-masked]] 
	Sent: Tuesday, May 12, 2009 12:18 PM
	To: Lentini, James
	Cc: Everhart, Craig; Robert Thurlow; [email-masked]
	Subject: Re: [nfsv4] Last call for "Requirements for Federated
File Systems" (end May 20th)

	It is true that FSNs aren't memorable  But server Y need not
know the FSN of the fileset 
	it is hosting. That mapping may just be in the NSDB.  In that
case server Y will need to contact some NSDB (does it know which one) to
find out the FSN. 
	I am not sure if the  current admin protocol includes this
interface? 

	renu

	On Tue, May 12, 2009 at 8:40 AM, James Lentini
<[email-masked]> wrote:

		 There are many possible variations to this procedure,
...
		
		The example is describing one way a junction could be
created, but
		there are others. As Craig notes, the example is
describing the case
		where the FSN is not well known to the administrator.
Alternatively,
		the administrator could already know the FSN, which is
the case I
		think Rob and Renu have in mind.

		
		---
		
		  Given a local path, a remote export and a path
relative to that
		  export, an administrator can create a junction from
the local path
		  to the path within the remote export.
		
		  There are many possible variations to this procedure,
depending on
		  how the junctions are represented and how the
information necessary
		  to perform resolution is represented by the server.
		
		  Steps 1 and 2 are the only step that uses the
federation
		  interfaces.  The remaining step uses platform-specific
		  interfaces.

		  1.  The administrator MAY contact server Y, which
hosts the remote
		      export, and ask for the FSN of the target fileset,
given its
		      path relative to that export. Alternatively, the
administrator
		      MAY known the FSN a priori.
		
		  2.  The administrator requests server X to create a
junction at the
		      given path to the FSN of the target fileset on
server Y.
		
		  3.  Server X inserts the junction to the FSN, at the
given
		      path, into its local filesystem.
		
		---

		> > > We are starting the working group last call for
"Requirements for
		> > > which is located here:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqt
		> > > s-02.txt
		> >     1.  Contact the given file server with the given
local
		> > path and FSN

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 12 May 2009 11:55:16 -0600

Everhart, Craig wrote:
> memorable.

But why did the admin tool ever have time to forget it?  The
simplest example, it seems to me, is this:

- know an FSL path
- create a new FSN in the NSDB
- bind the FSN to the FSL in the NSDB
- create a junction on some server:/path with the FSN

If you do it all in one motion, a program just has to not free
memory too soon :-)

Yes, there are other use cases; I just think the one there
is not helpful.

Rob T

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 12 May 2009 11:56:09 -0600

Everhart, Craig wrote:

> matches an FSL?  Is this specified?

I think that, logically, we should search the NSDB.  If you
have the FSN anywhere, it should be there.  By what you can
search is perhaps another thing.  Stepping back, I'd prefer
to search the virtual namespace we're creating - "give me the
FSN for /nfs4/sun.com/home/thurlow - then I'll add another
FSL to represent the copy I made".

I begin to understand why we had talked about having more
info in the NSDB.

Rob T

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 12 May 2009 12:00:55 -0600

> I'd propose re-wording section 4.3 as follows:

I don't think this made anything simpler, so I would suggest
leaving it as-is if you don't like my wording.  I think the
problem is that we're not dealing with the simplest case.

Rob T

---

From: James Lentini <[email-masked]>
Date: Tue, 12 May 2009 14:33:15 -0400 (EDT)

On Tue, 12 May 2009, Robert Thurlow wrote:

> leaving it as-is if you don't like my wording.  

> - create a junction on some server:/path with the FSN

are already described in section 4.1 "Create a Fileset and its 
FSL(s)". We could describe them again here, but I don't think that is 
necessary (see below).

> I think the problem is that we're not dealing with the simplest 
> case.

The example could be simplified if it assumes the FSN is known at the 
outset. As we've discussed, there are multiple ways to determine an 
FSN, and these are not particularly relevant to the process of 
creating a junction. I believe this revision will make the example 
clear:

---

   Given a local path and the FSN of a remote fileset, an administrator 
   can create a junction from the local path to the remote fileset.

   Step 1 is the only step that uses the federation interfaces.  The 
   remaining step may use platform-specific interfaces.

   1.  The administrator requests the server to create a junction to 
       the FSN of the remote fileset at the given path.

   2.  The server inserts the junction to the FSN, at the given 
       path, into its local filesystem.

---

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 12 May 2009 12:54:15 -0600

> FSL(s)". We could describe them again here, but I don't think that is 

Agreed, just providing context.

> I believe this revision will make the example clear:
> 
> ---
> 

That works better for me, thanks!

Rob T