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

From: Jim Rees <[email-masked]>
Date: Sun, 16 May 2004 16:29:07 -0400

The current plan is to return NFS4ERR_NOENT for a READDIR of the NFSv4 
  pseudo root.

That seems wrong to me.  It would imply that the root does not exist, and in
my opinion would violate the spec.  I think you want something more like
NFS4ERR_ACCESS.

Other than that, an unreadable root seems acceptable, although unfriendly.
Why not put your flat file system somewhere below the root, and make that
unreadable?

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

---

From: Jim Rees <[email-masked]>
Date: Mon, 17 May 2004 14:03:59 -0400

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.

Just make sure you return NFS4ERR_ACCESS, and not an empty directory or some
other lie, and you'll be fine.  Clients will be happier if they do a subdir
mount instead of mounting the root, but that's not your problem.

---

From: "Halevy, Benny" <[email-masked]>
Date: Mon, 17 May 2004 15:59:54 -0400

This would be somewhat similar to what you'll return for MOUNTPROC3_EXPORT

Benny

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Haynes, Tom
>Sent: Monday, May 17, 2004 3:08 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: [nfsv4] FYI: Readdir not allowed on NFS pseudo root
>
>
>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.
>> > 
>> -- 
>> Tom Haynes, ex-cfb
>> [email-masked]
>-- 
>Tom Haynes, ex-cfb
>[email-masked]