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

From: Jim Rees <[email-masked]>
Date: Mon, 17 May 2004 07:15:57 -0400

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 17 May 2004 09:48:25 -0500

> the only acceptable response.

I don't have a strong opinion.  Either response will likely be a call
generator for the interactive user: "I don't see the files I expect to 
see"
or "I get an error when I try to 'ls' the directory".

With tongue firmly planted in cheek, the server could respond to
the READDIR response with a single entry with a name of:
	"This server does not support the READDIR operation"

---

From: Stevan Steve Allen <[email-masked]>
Date: Mon, 17 May 2004 10:11:23 -0600

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:

and uses the cached copy for subsequent lookups.  I think NFS4ERR_ACCESS 
is

---

From: Stevan Steve Allen <[email-masked]>
Date: Mon, 17 May 2004 09:18:28 -0700

Clarification:  Except for the v4 pseudo root, the server supports 
readdir,

Thanks,
Stevan C. Allen

> the only acceptable response.

Spencer wrote:

---

From: Stevan Steve Allen <[email-masked]>
Date: Mon, 17 May 2004 10:29:04 -0700

It may be helpful to point out that the server READDIR restriction on the 
v4 root can be detected by the client.  Both read mode bits will be off. 

I'm not client savvy, but if the client creates a name space cache, the v4 
pseudo root may appear as a hidden or restrictive access dir (r+w mode 
permission bits off, DOS hidden attr not supported). 

In contrast, client apps may still have r+w access to the objects 
contained in the v4 root dir (determined from lookup).  It will be likely 
that lookup will return a 2nd level dir object with the read mode bits on, 
allowing READDIR from this point on. 

Initially empty (no READDIR from the root) an ideal client may build a 
name space cache from the restrictive root via lookup and readdirs (when 
read mode bits are on).  Hopefully, no special treatment is needed by the 
client.

Thanks,
Stevan C. Allen

---

From: Stevan Steve Allen <[email-masked]>
Date: Mon, 17 May 2004 10:43:05 -0700

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.

-- 
Tom Haynes, ex-cfb
[email-masked]

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 17 May 2004 10:01:52 -0700 (PDT)

/   (p)
                  / -------+-------------\
                FS1 (p)                  FS2 (p)
           /----+------\                  |

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

-- 
Tom Haynes, ex-cfb
[email-masked]

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 17 May 2004 12:07:54 -0700 (PDT)

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)
           /----+------\                  |
                          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 Haynes, ex-cfb
[email-masked]