Subject: Re: Updated READDIR

From: Peter Staubach <[email-masked]>
Date: Thu, 4 Nov 1999 16:27:30 -0800 (PST)

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

So, just to be consistent, the count portion of the READ request
becomes a hint as well?  The server is free to return more or less than
what the client requested?

I don't see how calling things `hints' simplifies anything.  Clearly
specifying the semantics does this all by itself.  On top of that, all
of these issues regarding XDR encoding have already been solved and the
solutions are well known.  Is there really a desire here to solve non-
problems?

> > 
> > Is this a good general direction for the protocol to move in?  It seems
> > questionable to me.
> 
> 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.
> 

Yes, I realize that NFS Version 4 has moved in both directions, but not
on the same operation.  Things which used to be fairly simple are now
getting more and more complex, for no obvious benefit.

I keep looking at all of this flexibility being built in, and I keep
thinking about how it will be implemented, and the bottom line is that
the client is pretty much going to continue working pretty as it always
has because it is driven by system calls from applications.  The format
of the RPC messages being generated may change, but they won't be
particularly different than they ever have been.

Mostly I see the servers, which have to support this growing protocol,
getting more complicated and thus getting slower.  The interesting
thing that real file systems do, store and supply user data, isn't
particularly changed from older versions of the NFS protocol.  The
metadata operations are getting more and more flexible, but to what
end?  Was there ever a clear statement of the problems that the old
facilities failed to address or that these new facilities are designed
to address?  How is the question of whether the new protocol is better
than older protocols or merely different going to be answered?

	Thanx...

		ps

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 04 Nov 1999 19:53:27 -0600

> what the client requested?

Obviously not.  The NFS protocol defines a file as an array of bytes.
It is an agreed upon format where the data length is well known and the
write request can be satisfied exactly.  Therefore,
the server doesn't have any problems satisfying the count exactly.
The server is free to return less data if it wants.

Directory contents are obviously structured but we are specifying the 
READDIR in bytes, not in the number of records to read.  To make the interface
work 'logically' the count should be the number of records to read
from the directory.  Unfortunately, the APIs at most clients and servers
are not constructed to make this transition easy

> solutions are well known.  Is there really a desire here to solve non-

The dircount field is a hint; I believe we have agreed on that.
The maxcount field has been proposed as a hint as well.  If it remains
to be a hint and the server can return less than maxcount and more than
maxcount by no more than one entry, then this seems to simplify the
encoding logic (even though the hard logic has been done for older
implementations).

If maxcount is a hard limit, the XDR encoding logic will need to be
extended to the new attribute encoding model and based on the comments
from the bakeoff this model is a little more difficult to deal with.
I don't have personal experience with it yet and therefore am working
from other's comments.  Having maxcount be a 'soft' limit seems to
be a win here.  If maxcount stays as a hard limit, we should introduce
another error code (i.e. NFS4ERR_READDIR_NOSPC) in the event the
client does a READDIR with a maxcount that is insufficient for the
result.  Then the client will need deal with this error on the 
READDIR path as well.

> than older protocols or merely different going to be answered?

The working group charter and "NFS Version 4 Design Considerations"
http://www.ietf.org/rfc/rfc2624.txt are the guides here.

The Design Considerations document addresses the issues in general terms.

It was reviewed and approved by the WG and the IESG so it seems like
it is represents the rough consensus of the WG for NFSv4 features.

It seems obvious to me that for the major features the protocol, NFSv4
is better than NFSv2/v3.  Right now I am attempting to clean up the
details so that we can bring the document to closure.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Thu, 4 Nov 1999 19:34:05 -0800 (PST)

> from the bakeoff this model is a little more difficult to deal with.

Right. With v3's readdirplus, we could predict this handle this
better because  fattr3 was fixed size and the server could fix the file
handle size, despite it being variable lenght. Both assumptions are
off with a v4 implementation.

What I did at the bakeoff was keep getting attributes until I had overflown
maxcount, and then I had to free the storage for the last directory entry's
attribute. I only counted the xdr encode sizes of fattr4's plus the native
directory size. So this was technically wrong. But it was easy and it did
serve the purpose in injecting flow control.

According to the nfs v3 specifciation, READDIR3 (not READDIRPLUS3) has only
a count, which is like dircount, and i defined with similar prose as
READDIRPLUS's dircount. If dircount is a hint, then READDIR3's count is a hint.

I'm confused as I was at the bakeoff! If performance issues are an
overriding concern for leaving maxcount as a hard limit, then why isn't
performance an issue with READDIR3's single soft limit? Can't the server
return orders of magnitude more bytes in READDIR3res than the client asked
for? Why didn't READDIR3args have a maxcount too?

This is why I've been having trouble getting it.

I understand now why dircount is a native count. It should be left as such,
for the performance optimization reason Peter mentioned in this e-mail thread.
But READDIR3 (not READDIRPLUS3) is broken.

> If maxcount stays as a hard limit, we should introduce
> result.  [...]

This seems like the cleanest approach. Otherwise the server is forced to
perform in-line XDR calculations. The client will need to avoid asked for
variable/unlimited length attributes (.e.g ACLs) if it wants to avoid
unpexpected NFS4ERR_READDIR_NOSPC errors. But with any other
alternative, short of treating maxcount has a pure hint, the client would want
to avoid asking for variable/unlimited length attributes as well, to
avoid small dirlist4 lists, especially zero length ones.

	-mre

---

From: Brent <[email-masked]>
Date: Thu, 04 Nov 1999 20:25:34 -0800

Count me in favor of maxcount being a hard limit.

The name "maxcount" does imply a maximum number of
bytes returned.  As a client, I might be mildly 
upset if a server returned way more data than
I asked for - just because its XDR encoding got
a bit carried away.

Keep in mind that the server could potentially
overshoot by a huge amount if one or more attributes
is big, e.g. an ACL with lots of entries.  If the
server overshoots the maxcount - I'd rather the
server not bother to return the extra data, than
to have it transmitted across the wire so that
the client can throw it away.

Like Eric, I found the XDR encoding to stay within
maxcount quite simple.  I just mark a position in 
the XDR stream at the beginning of each entry.
If I overshoot maxcount, I move the XDR offset
back to the last valid marker.

Let maxcount be a max count.

	Brent