Re: [nfsv4] NFSv4 Referral handling by client

[Trond Myklebust <[e-mail]>]

On Fri, Nov 14, 2014 at 7:14 PM, Rahul Shah <[e-mail]> wrote:
> I am working NFSv4 referral implementation on the server side and noticed
> one of the occasion client never requested GETATTR with fs_locations even
> though server returns NFS4ERR_MOVED.
>
> I am running two set of test.
>
> TEST_1: works as expected and client is redirected to remote server.
>
> 1) Client mounts to server_a
> 2) cd /a/b
> 3) From the server set referrals on directory /a/b/c and point it to some
> remote server
> 4) cd "c"
> 5) What I observed is, client sends PUTFH (of "b"), LOOKUP (of "c"), GETFH,
> GETATTR
> 6) Server returns NFS4ERR_MOVED for GETFH
> 7) Clients sends PUTFH (of "b"), LOOKUP (of "c"), GETATTR (requesting
> fs_locations)
> 8) Server returns all referral information and client happily connects to
> server_b
>
> TEST_2 : Client never requests fs_locations
>
> 1) Client mounts to some path on server_a
> 2) cd /a/b
> 3) READDIR "ls" on /a/b which returns filehandle of "c"
> 4) From the server set referrals on directory /a/b/c and point it to some
> remote server
> 5) cd to "c"
> 5) While catching the tcpdumps, I observed client sending requests
>     PUTFH (of "c" it got fh from previous READDIR), ACCESS (of "c"), GETATTR
> (without fs_locations)
> As per RFC 3530, NFS4ERR_MOVED is a valid return code from ACCESS.
>
> From the server I tried returning NFS4ERR_MOVED for ACCESS. Client just
> gives up  and NEVER sends  PUTFH (of "c"), LOOKUP (of "c"), GETATTR
> (requesting fs_locations)
> I also tried returning NFS4ERR_MOVED for PUTFH. Client again gives up  and
> NEVER sends  PUTFH (of "c"), LOOKUP (of "c"), GETATTR (requesting
> fs_locations)
>

A full description of how NFSv4 referrals are expected to work can be
found in the section on "absent filesystems" in the latest draft of
RFC3530bis:
    http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-34#section-8.2

If you read through that, you will see that the most likely cause of
the client's confusion is that your server returned a filehandle in
the READDIR operation. Most existing clients expect that a server that
has an absent filesystem will instead implement the behaviour
described in
    http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-34#section-8.3.2

Cheers
  Trond