Committed to CVS repository.  Will be in draft-09.  Re-assigning to Spencer.

We have the text.  If there are are no issues with it in the next few days, I
will submit the change.

Let's have the discussion on the alias if anywhere.

On Oct 23, 2006, at 8:42 AM, Dave Noveck NFSv4.1 Issue Tracker wrote:

>
> Dave Noveck <dnoveck@netapp.com> added the comment:
>
> Mike wrote:
>> So indicating at create session time is what I had in mind.
>
> I'd hate to have the situation where a single client had multiple  
> sessions and
> only some of them allowed migration.  I think this would be getter  
> as a
> per-client attribute set at EXCHANGE_ID time.
>
> So I'd propose adding a flag word eai_flags to the EXCHANGE_ID  
> arguments and
> defining EXCHANGE_ID_FLAG_SUPPORT_REFER and  
> EXCHANGE_ID_FLAG_SUPPORT_MIGR.  The
> reason for two bits is that I can well imagine clients that support  
> MOVED in the
> referral context without supporting it in the migration context.   
> In the even of
> a change of bits on a subsequent EXCHANGE_ID, the server should  
> accept the last
> state, but clients should not depend on a prompt change so that it  
> can still get
> a MOVED a little bit after the change it has no cause for  
> complaint.  When the
> bits are set with a new client_owner4 (new verifier presumably),  
> this will be
> acted on immediately.
>
> ___________________________________________________________
> "NFSv4.1 Issue Tracker" <issue-tracker@nfsv4-editor.org>
> <http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue52>
> ___________________________________________________________

Mike wrote:
> So indicating at create session time is what I had in mind.

I'd hate to have the situation where a single client had multiple sessions and
only some of them allowed migration.  I think this would be getter as a
per-client attribute set at EXCHANGE_ID time.

So I'd propose adding a flag word eai_flags to the EXCHANGE_ID arguments and
defining EXCHANGE_ID_FLAG_SUPPORT_REFER and EXCHANGE_ID_FLAG_SUPPORT_MIGR.  The
reason for two bits is that I can well imagine clients that support MOVED in the
referral context without supporting it in the migration context.  In the even of
a change of bits on a subsequent EXCHANGE_ID, the server should accept the last
state, but clients should not depend on a prompt change so that it can still get
a MOVED a little bit after the change it has no cause for complaint.  When the
bits are set with a new client_owner4 (new verifier presumably), this will be
acted on immediately.

assign to Dave based on wg concall

--- "Dave Noveck \"NFSv4.1 Issue Tracker\""
<issue-tracker@nfsv4-editor.org> wrote:

> 
> Dave Noveck <dnoveck@netapp.com> added the comment:
> 
> If a filesystem has moved and it is inaccessible then the client has
> to get some
> indication that he can't access it.  I think eevery client should be
> able to
> accept NFS4ERR_MOVED and turn it into an applicatin if they can't do
> anything
> better.

As server implementer I'd like to know if the client is going
return this error to the application or handle it. If it is
the former, then as a server implementer, I won't return
_MOVED, if I can do something else (e.g. redirection ala
ONTAP GX).

So indicating at create session time is what I had in mind.

If a filesystem has moved and it is inaccessible then the client has to get some
indication that he can't access it.  I think eevery client should be able to
accept NFS4ERR_MOVED and turn it into an applicatin if they can't do anything
better.

One case where this might be valuable is where you have multiple paths to a file
system and the server would prefer use of alternate path but can support access
thorugh the current path albeit less efficiently.  In this case, returning MOVED
to cleints which can support migration is desirable.

However, another way to address this issue is to take advantage of
fs_locations_info.  If you present the alternate path as a higher-priority
replica, then cleints which support migration would switch and those that
couldn't wouldn't.

In order to enable this, I would change the second paragraph of section 10.4.1
to be:

The client can use the fs_locations_info information to select a replica of
higher priority if such exists, or savesinformation about alternate replicas for
later use.  In the event that server failures, communications  problems, or
other difficulties, make continued access to the current replica impossible or
otherwise impractical, the client can use the alternate replica locations as a
way to get continued access to his data.

There's no point in sending NFS4ERR_MOVED if a client can't deal with it.