Subject: RE: POSIX compliant READDIR

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 23 Jul 2001 11:26:24 -0700

Brent wrote:
> NFS version 4 LOOKUPs are required to cross mountpoints on the server.
> Clients can detect a mountpoint crossing by noticing the change in
> the fsid attribute, and can preserve POSIX semantics (fids are unique
> within a fsid) by doing a mount in their own namespace.

> However, the treatment of mountpoints by READDIR is not currently
> defined in RFC 3010.

> If any of the entries in a READDIR response is mounted-on, then
> it must return the attributes of the mounted-on directory - not
> the mounted directory.  The attribute at issue is the fid.
> POSIX requires that the fids returned in READDIR entries be
> unique and belong to the filesystem of the directory.

> I propose a sentence in the READDIR description to indicate
> that the attributes returned for mounted-on directory entries
> must be those of the mounted-on directory - not the mounted
> directory.

You're assuming a lot of implementation context about how mounting
works in UNIX, aren't you?

I think you are going to have at least a paragraph to explain how 
this all works, especially with respect to the pseudo fs, in which
the roots of the various real fs's are not necessarily mounted
on any real directories that the client can see.

> This requirement raises a couple of issues:
> 
> 	- A client that aggressively caches file attributes for
> 	  directory entries must distinguish between attributes
> 	  obtained via READDIR and those obtained via LOOKUP,
> 	  since they may be different at entries that are mountpoints.

Dealing properly with the cases of things becoming and ceasing
to be mountpoints or having different fs's mounted on them, is left
as a exercise for the client implementor.

>	  It would be useful to have a boolean "mountpoint" attribute
> 	  to indicate whether the attributes belong to a 
> 	  directory entry that is mounted-on.

It may be essential for the above.

> 	- User-level servers do not have direct access to the attributes
> 	  of mounted-on directories, though they do (on UNIX systems)
> 	  have access to the mounted-on fid via a getdents() call to
> 	  the parent directory.  In this case, a user-level server
> 	  would return "true" for "mountpoint" and return just
> 	  the fid attribute.

I think he should return something reasonable in rdattr_error.

Note that the fileid attributes is optional so even this might not
be returned.

Also, I think any server should refuse to return the filehandle
attribute in this case.  If we allow filehandle to be returned
in this case that we now have two filesystsem objects that live at
the same place in the name space (but are obtained by different
operations) and have different use characeteristics (I expect that 
the one returned by READDIR would be useless) so it would be better
to say you can get the attributes for the directory entry via READDIR
(and not by using the handle returned by READDIR for a GETATTR) but the
only handle you can get is the one you get via LOOKUP.

> So, I'm proposing:
> 
> 	1) Additional wording in READDIR: that if any directory entry
> 	   is mounted-on, the attributes of the mounted-on directory
> 	   are to be returned.
> 
> 	2) A new, non-mandatory, boolean attribute "mountpoint" that
> 	   indicates whether the directory is mounted on.
> 
> I'm interested in how these semantics would affect other, non-POSIX
> implementations.

---

From: Brent <[email-masked]>
Date: Mon, 23 Jul 2001 15:16:29 -0700

> works in UNIX, aren't you?

Certainly, though I'm being more politically correct in referring
to POSIX so as not to offend users of POSIX capable OS's that
do not consider themselves "UNIX" :-)

> on any real directories that the client can see.

It doesn't really need a paragraph, just a sentence that says
fids of directory entries must be unique within the filesystem
of the directory.

We don't need to say anything special about pseudo filesystems.
They have no special semantics in the protocol and are 
indistinguishable from real filesystems (from the client's
point of view).

> >         directory entry that is mounted-on.

Right, it's an implementation feature - an optimization.

> I think he should return something reasonable in rdattr_error.

But a user-level server can return something - it's not a complete
failure.  Just getting the inode number and filetype is probably
enough for most clients.

> Note that the fileid attributes is optional so even this might not

True. I that case the user might have an unpleasant time if he/she
expects POSIX semantics.  But even without a fid, you can probably
still get in there and read/write files.

> only handle you can get is the one you get via LOOKUP.

Yes, that makes sense.

	Brent