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

["Haynes, Tom" <[e-mail]>]

I was assuming that USER1 and USER2 were exportable.

You have some means of exporting objects in FS1.   In the example you
gave, that was:
USER1, USER2, and PROJECTS/PROD

You can take your list of exports, which I assume is in something
like /etc/exports, and construct your pseudo-fs:

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

Here I've stripped out the ones in FS1 which are real but your
server has no way to query: PROJECTS/PROD1 and PROJECTS/ETC.

The point is that you can weave together a name space out of the
set of exports presented for v3.



> 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]
> 


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

_______________________________________________
nfsv4 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4