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

[Stevan Steve Allen <[e-mail]>]

Tom,  In your example, the NFS server has no way to query the kernel to 
obtain {USER1, USER2, PROJECTS}.  The limit to the number of entries under 
FS1 is Approx 0.5 trillion.

Thanks,
Stevan C. Allen

"Haynes, Tom"  wrote:

Why can't you just stich together the parts which are available with
pseudo entries?

                           /   (p)
                  / -------+-------------\
                FS1 (p)                  FS2 (p)
           /----+------\                  |
        USER1  USER2   PROJECTS (p)      HFS (p)
                           |              |
                           |             ETC
                           |
                  /--------+-----\
               PROD1 (p)  PROD2   ETC (p)


We have a disjoint FS space as well, and our root is really pseudo:

                          / (p)
                          |
                         vol (p)
                          |
                 +--------+-----------+
                 |        |           |
                vol0    vol1        smitty (p)
                                      |
                                    xavier

The point is that your pseudo-fs need not mimic the fs on your disks.
It just needs to present a gateway to all of your entry points.  Also,
even if a node corresponds to a physical directory, you do not need
report the attributes of that directory entry.  I.e., fudge the results.

> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 


-- 
Tom Haynes, ex-cfb
[e-mail]