Subject: RE: [nfsv4] pNFS issues/changes (draft-welch-pnfs-ops-02.txt)

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 1 Aug 2005 12:08:17 -0400

Mark Eshel wrote:
> This sound like a good idea. Do you still have time to start new 
> extensions for 4.1?

I'm not sure whether you mean to fit within some deadline for 4.1
extensions (is it already too late?) or time for me to actually do
the work?

If the first, the answer is "I don't know".

And if the second, the answer is "I don't know" as well.

Let me try to clarify these. :-)

The issue of when to close the door on new material is one the that
the working group has to decide and presumably will be discussed in
Paris.  I've discussed this with Spencer who feels there will still
be room for "small" items for a while, with the definition of "small"
being somewhat elusive.  My feeling is that we do have to close the door
at some point but the nature of what we are doing does not really 
admit of a fixed cutoff.  I do think that new big items should be
off the table but that for smaller items such as new attributes, we 
have room for a while (with the definition a "a while" being something
the working group needs to decide on).  Also, the decision on any 
particular item is up to the working group and it is just a fact 
that things that we think are important and needed will wind up
looking smaller and more manageable to us than things that just seem
like a nice idea.  As time goes on, we will have to raise the bar
though or else v4.1 will never get done.  Expect to hear me (and 
everybody) on all sides of this issue as each case will pose its
own unique issues.

What we are talking about here is an attribute but is one that has 
significant implications so it certainly isn't tiny, so if we are going
to add this, "'twere well it were done quickly" or at least realtively
so.

As to my time, as I indicated, I'm unsure about this.  I've just come
back from vacation and my available free time is even more non-existent
than usual. 

Trying to come up with a schedule for an initial I-D just doesn't seem
possible.  What I will try to do over the next week is to come up with 
some mail laying out a possible approach, so that the working group can 
discuss it.  If there is sufficient interest, I will try to square the 
circle as far as my own time commitment to get an I-D out is concerned.

-----Original Message-----
From: Marc Eshel [mailto:[email-masked]] 
Sent: Monday, July 18, 2005 10:14 PM
To: Noveck, Dave
Cc: Dean Hildebrand; Goodson, Garth; [email-masked];
[email-masked]
Subject: RE: [nfsv4] pNFS issues/changes (draft-welch-pnfs-ops-02.txt)

"Noveck, Dave" <[email-masked]> wrote on 06/21/2005 01:51:07 PM:

> > With fs-locations we give the client a list of metadata server 
> > that can act as the server for given filesystem and the client 
> > can choose which one to use and switch among them at will or 
> > because of some failure. 
> 
> The problem is that in v4.0 as it stands there is an enormous
> range of ways that a client can interpret the fs_locations list:
> 
> "Here is a list of servers and you can switch when there is failure,
> after refetching your change attibutes (because change attribute
> is within the purview of a particular server)."  (and that is not the
> most extreme case of discontinuity -- some people are thinking that 
> filehandles and fileids will just change or that you may wind up
> with a slighly out-of-data version of the data).
> 
> "Here is a list of servers and you can switch when there is a 
> failure with no discontinuity of access (changes in fh's, stateid's,
> fileids, change attributes), although changing is a big deal
> and you shouldn't do it without good cause."
> 
> "Here is a list of servers and you can switch when there is a
> failure with no discontinuity of access or even at will since
> there is no big cost to switch."
> 
> "Here is a list of servers and you can access any of these 
> servers as you will at the same time (multi-pathing or a 
> cluster fs) since they are all effectively the same thing".
> 
> The problem is that the client only knows about the list and
> has no way of knowing which of the statements above is associated
> with the list of servers he is getting.  I have been thinking
> about a locations_info attribute for 4.1 that would allow the
> server to tell the client which of those he meant and also 
> give preference information (local vs. remote copies, absolutely
> up-to-data vs. slightly out-of-data copies).
> 
This sound like a good idea. Do you still have time to start new 
extensions for 4.1?
Marc.

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

---

From: Brent Welch <[email-masked]>
Date: Tue, 02 Aug 2005 05:16:25 -0700

> to add this, "'twere well it were done quickly" or at least realtively

I feel we need more than just an attribute that lists the
metadata servers for a file system.  You'll also want, or at
least I do, some way to say "this file is controlled by
that server" - in other words, a more specific thing than
"this file system is controlled by that group of servers"

[nothing new below here]

>>>"Noveck, Dave" said:
 > being somewhat elusive.  My feeling is that we do have to close the =
 > door
 > some mail laying out a possible approach, so that the working group can =
 > 
 > "Noveck, Dave" <[email-masked]> wrote on 06/21/2005 01:51:07 =
 > PM:
 > 

--
Brent Welch
Software Architect, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email-masked]