Re: [nfsv4] FYI: Readdir not allowed on NFS pseudo root

I also suspect ACCESS is the only available READDIR response, and our 
design doc should be updated.

For NFSv3 we do not allow a mount on the flat fs root.  Mounting siblings, 
in effect, creates "disconnected" tree structures described below.  Mount 
and lookup provided the server a starting point (i.e. USER1).

The problem is due to the mentioned kernel restriction.  Where the server 
can not obtain all the parent dirs (USER1, USER2..) shown in the FSYS1 
sample below.

---- FSYS1 ----
/USER1  <-v3 mountpoint
        |- PROJ
        |- SETUP
        '- ETC

/USER2  <-v3 mountpoint
        |- PROJ
        |- SETUP
        '- ETC

/PROJECTS
        |- PROD1
        |- PROD2  <-v3 mountpoint
        '- ETC

---- FSYS2 ----
/HFS
        '- ETC  <-v3 mountpoint

Our current decision is to make the new v4 root to be the restrictive flat 
fs root (this discussion).  Where '/HFS' represents crossing a mount 
point. 

The idea of returning an empty dir list for the v4 root is interesting, if 
clients update their cached name space from lookups and mounts. 

Jim Rees Wrote:

  Seems like the server would return an "empty" response for READDIR
  on this special server.

But that would be wrong too.  That would imply the directory is empty.  I
can imagine a client that would get very confused by this.  Suppose, for
example, the client caches directory contents after a successful READDIR,
and uses the cached copy for subsequent lookups.  I think NFS4ERR_ACCESS 
is
the only acceptable response.

  This also implies that clients must use LOOKUP to traverse the
  server's namespace on things like traditional mount operations that
  a client would do.

Yes.  The client must be prepared for this anyway.  In fact, the client
probably can't tell and doesn't care whether it's in a pseudo-fs or a real
one.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4