Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010

From: James Lentini <[email-masked]>
Date: Fri, 1 Oct 2010 09:50:48 -0400 (EDT)

On Thu, 30 Sep 2010, Trond Myklebust wrote:

> On Thu, 2010-09-30 at 17:33 -0400, James Lentini wrote:
> > 
> > On Thu, 30 Sep 2010, Chuck Lever wrote:
> > > Some convention for the NFS server's reply in this case should be 
> > > agreed upon outside of the ongoing FedFS discussion.
> > 
> > I think another way to phrase this question is: How does an NFS server 
> > indicate that a file system has moved to an unknown location? One 
> > obvious possibility is to return a zero element locations array in the 
> > fs_locations structure.
> 
> NFS4ERR_STALE is the usual response. If you don't know where the 
> filesystem was migrated to, then what you have is not a migration 
> event. It is an unexport of the partition.

Suppose the server waits to resolve the junction until a GETATTR that 
includes fs_locations[_info]. If the server has already responded with 
an NFS4ERR_MOVED, will an NFS4ERR_STALE return for the GETATTR be a 
reasonable response to the client?

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 01 Oct 2010 09:58:48 -0400

> reasonable response to the client?

I'm not sure I understand. If the location of the filesystem is unknown,
then why would the server reply with NFS4ERR_MOVED in the first place?

That said, I believe that the answer to your question is 'yes'. See for
instance the discussion in section 4.2.2 in RFC3530.

---

From: James Lentini <[email-masked]>
Date: Fri, 1 Oct 2010 10:22:56 -0400 (EDT)

> then why would the server reply with NFS4ERR_MOVED in the first place?

I think there are a few scenarios where this might happen. 

Suppose the client issues the operations in Section 11.8.1 of RFC 
5661. The server will respond to the GETFH with an NFS4ERR_MOVED. A 
server could delay resolving the junction at /this/is/the/path until 
the client sends a GETATTR for /this/is/the/path that includes 
fs_locations[_info] (at which point the resolution might fail) or the 
server might have a cached value for the junction that expires between 
receipt of the GETFH and GETATTR (and the new resolution might fail).

> That said, I believe that the answer to your question is 'yes'. See 
> for instance the discussion in section 4.2.2 in RFC3530.

Thanks. I think we have our answer. The server should return 
NFS4ERR_STALE in these instances.

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 1 Oct 2010 10:49:30 -0400

> -----Original Message-----
> From: Lentini, James
> Sent: Friday, October 01, 2010 10:23 AM
> To: Trond Myklebust
> Cc: [email-masked]
> Subject: Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010
> 
> 
> 

Another scenario is if the filesystem was actually moved away from the
server in question, but the server is unable to tell you where the
filesystem has gone due to some resolution error.

I agree with the NFS4ERR_STALE idea for such a case.

		Craig

---

From: Robert Thurlow <[email-masked]>
Date: Fri, 01 Oct 2010 09:02:20 -0600

> reasonable response to the client?

If the servers have some issue with waiting for things to
settle, NFS4ERR_DELAY is available.  If the server just
has nothing good to say, NFS4ERR_STALE is final and fatal
to whatever the client was trying to do.

Rob T

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 1 Oct 2010 10:11:25 -0500

> I agree with the NFS4ERR_STALE idea for such a case.

And then this gets called out in the draft?

FWIW - this can happen in a base NFSv4.0 system. A filesystem is migrated,
the server gives the client back NFS4ERR_MOVED and when the client
asks for fs_locations, that info has been lost.

I think I'm going to add some text to 3530bis to cover this :->.

---

From: Robert Thurlow <[email-masked]>
Date: Fri, 01 Oct 2010 09:15:55 -0600

> I think I'm going to add some text to 3530bis to cover this :->.

I agree - another path implementors have is to decline to
return the fs_locations attribute, but it seems to me that
this is not as clear about the nature of what's happened.

Rob T