Subject: RE: [nfsv4] NFS4ERR_MOVED_DATA_AND_STATE

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 4 Apr 2006 13:16:34 -0400

I'm in the process of drafting a new chapter on migration,
replication, and referral, and I'm including fs_locations_info,
although pruned a bit.  Also I'm re-organizing things a bit 
to make it a bit easier to understand (I hope).  

I made the decision to go in that direction without a clear 
consensus, with the expectation that we could simplify this
stuff or otherwise alter it as part of the review of the 
v4.1 drafts.  While there was nobody in Dallas loudly chanting 
"We want fs_locations_info and we want it now", there was nobody
arguing against it and a number of people thought it was
needed and asking for extensions (or even more overkill :-).

As I've reviewed what RFC3530 says as part of the process of
drafting, I've become convinced that some sort of locations
info attribute is absolutely required.  That doesn't mean 
that we need everything that has been proposed to be in it,
but as you indicate there is some additional migration/replication
information needed and it makes sense to provide that in an 
attribute.  I'd hope that we can consolidate the information 
and avoid a succession of ad hoc attributes to solve specific
problems.

Anyway, I'd like to understand what your minimum requirement
is and try to see what other people absolutely must have, and
then see if we can create something that includes at least that 
core, plus other things that people believe are nice-to-haves 
without getting too far into the land of overkill. Whether
that's in the form of "this is all that I need that is in 
fs_locations_info" or "here is what I need rather than 
fs_locations_info" doesn't really matter.

My expectation is that Spencer will incorporate my chapters in
the next draft which should be out around 4/10.  I'm going to
be on vacation 4/12-4-22 so I would expect that we would discuss
this stuff on the 5/2 conference call.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Tuesday, April 04, 2006 12:46 PM
To: [email-masked]
Subject: [nfsv4] NFS4ERR_MOVED_DATA_AND_STATE

NFS4ERR_MOVED_WITH_STATE was introduced to solve the problem that a
client has no reliable way to probe a new server to find out whether it
will respect the state that the client got from some old server.

It solves that problem only in one case, though--the case when the
migration is triggered by the server-returned error--and leaves out some
important cases such as failover.

I suppose it's partly for this reason that all the other information
relevant to migration is communicated in attributes, not encoded in
error returns.

Dave Noveck's locations_info proposal would address the problem, though
it's overkill for this case.  Are people still interested in the full
generality of locations_info, or should I propose something smaller?

--b.

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

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 4 Apr 2006 13:30:19 -0400

> to make it a bit easier to understand (I hope).  

OK.  In the interests of simplicity, then, I hope you can just take the
new MOVED error out at the same time locations_info is added, unless
someone can think of a really good reason to have both.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 4 Apr 2006 13:40:01 -0400

On Tue, Apr 04, 2006 at 01:16:34PM -0400, Noveck, Dave wrote:
> without getting too far into the land of overkill.

By the way, I think our minimum requirement is just that both possible
implementations of state migration--one that depends on servers sharing
state, and one that depends on clients reclaiming it--should be
possible.  And that this state sharing shouldn't be tied to other levels
of sharing, such as providing stable filehandles across migration.

(On Linux we just about have the filehandle-sharing non-state-sharing
approach implemented now, albeit scattered in various external patches,
so we expect that approach will mature before we get a mature approach
using state sharing--so this isn't just a theoretical concern.)

The last locations_info proposal I saw looked like it did all this.

--b.