Subject: Re: Updated READDIR

From: Peter Staubach <[email-masked]>
Date: Thu, 4 Nov 1999 15:34:08 -0800 (PST)

> 
> > 
> > Either they should be hints, or both not. Based on my understanding of Peter's
> > explanation, if only one is a hint it should be maxcount.
> > 

I guess that that wasn't my message, so clearly I wasn't explaining
things well enough.  Maxcount was designed to be a hard limit and
dircount was designed to be the hint.

Given this, then how does the client control how much data is being
sent to it?

> 
> > > For some file system environments, the directory entries "." and
> > >      ".."  have special meaning and in other environments, they may not.
> > >      If the server supports these special entries within a directory,
> > >      they should not be returned to the client as part of the READDIR
> > >      response.  To enable some client environments, the cookie values of
> > >      0, 1, and 2 are to be considered reserved and not used in READDIR
> > >      responses.
> > 
> > What do  1 and 2 correspond to. Can I use them READDIRargs?
> 
> Can not be used for the cookie value in READDIRargs (reserved in both directions).
> 

The server implementation is getting more and more complex, more and
more expensive to execute, and thus, slower and slower.  One of the
large advantages of previous versions of the NFS protocol were that
the servers will reasonably easy to implement and execute.  All of the
smarts was pushed on to the client.  This made the servers scaleable.
It also fit better within the SAN/NAS architecture where servers aren't
expected to be particularly high powered.

Is this a good general direction for the protocol to move in?  It seems
questionable to me.

		ps

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 04 Nov 1999 18:09:41 -0600

> Given this, then how does the client control how much data is being

It doesn't strictly control it.  If the client is concerned with
the size of the response (within the size of one additional directory entry),
then it should be careful to ask for none or a small set of attributes.
In fact that is a good comparison.  With the attribute model being used and
the ACL being an attribute, it is possible that with GETATTR the client
won't exactly how large the response will be.  So for a regular GETATTR,
the response is not bounded (so to speak).

Having maxcount be a hint, the encoding logic of the server is simpler
since it doesn't have to peek ahead or encode and then 'undo'.  This approach
also allows a server to return at least one directory entry to the client
when the maxcount is small compared to what the client asked for...

This seems to simplify both potential errors on READDIR because of
small maxcounts being used and the server implementation.

> Is this a good general direction for the protocol to move in?  It seems

NFSv4 has moved in both directions.  Things like 
file locking/lease management and mandatory security have added to 
the burden while the attribute model and volatile file handles have
eased the burden.  Overall, the implementation work is greater but
I think that the gains are worthwhile.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Thu, 4 Nov 1999 16:23:22 -0800 (PST)

> Is this a good general direction for the protocol to move in?  It seems

Reserving cookies 1 and 2 brought you to that conclusion. :-)

RFC 1813, the NFS V3 specification, was 126 pages. If the locking protocol
were better documented there so that people could implement it, it would have
been at least 150 pages. Add the status monitor which is integral to locking
and we'll call it 160 pages.

The NFS V4 specification sits at 211 pages. It does everything NFS V4 does,
but with more modularity and flexibility, and it includes an ACL protocol, a
caching protocol, i18n, and better interop with non-UNIX platforms. I suspect
Spencer might be able to keep in under 250. Maybe we can get his boss to tie
his next salary raise to that metric. :-)

Several folks in this WG have made repeated overtures to the SAN community.
This is an open process, and I'm sure if they had voiced opinions, the WG
would have listened carefully.  Nonetheless, there's reasonable subset of NFS
V4, that looks a lot like V3 (especially now that cookie verifiers are back
:-) ). SNIA thinks CIFS is a great protocol for SANS. I don't think NFSv4
compares that unfavorably with CIFS in terms of complexity. Might even be less
complex than CIFS; I've never seen the full CIFS spec to know for sure.

As for NAS, the folks who work for a certain NAS company were among those in
the WG who urged most strongly for ACL, caching, and file set protocols.

I've heard complaints before the bakeoff from at least one implementor about
OPEN, but a few days later he was done, and that was it. I didn't hear any
complaints from a Windows NFSv4 implementor about OPEN, which is good because
if there were, a certain ex-patriate Canuck would hear it from this
ex-patriate Canuck.

The numbered attribute stuff has a high potential for being implemented
inefficiently. My belief is that once we profile traffic, we'll find that
certain GETATTR4args bitmasks get requested more frequently than others, and
we'll be able to special case the handling to get fattr3 type performance.

	-mre

---

From: Uresh Vahalia <[email-masked]>
Date: Thu, 04 Nov 1999 20:40:44 -0500

> Is this a good general direction for the protocol to move in?  It seems

Amen.  I have repeatedly echoed this sentiment, but I guess people feel it more
important to complete the protocol and start implementing it.