Subject: Re: READDIR cleanup

From: Peter Staubach <[email-masked]>
Date: Tue, 2 Nov 1999 17:00:58 -0800 (PST)

> 
> If we are supporting file set migration in the NFS V4 protocol, don't we need
> the cookieverifier to allow the secondary server to indicate that the cookies
> used before won't work? Simply declaring that after a migration, the
> cookies can no longer be used is inflexible ... some file set transfer
> can preserve cookies, such as moving removable media from one server
> to another.
> 

What, in the context of file set migration, should a client do when
it receives such an error?

> 
> Given that NFS V4 is intended to be more hetereogeneous than
> NFS V3, that doesn't seem like sufficient grounds for retaining dircount.
> 

Heterogenuous or not, isn't simply being useful, grounds for being
in the protocol?

> What would be the consequence between "some client/server combinations" if
> the only thing transmitted is a maxcount?
> 

The consequence is that the server would always be returning either too
much data or not enough.  It is not the maxcount which is the interesting
counter here, it is the count of directory bytes which are returned.

> 
> The confusion is whether either a hint, whether it is fatal to go beyond the
> hint, and if maxcount is a maximum bound on XDR encoded data, then why don't
> implementations use xdr_sizeof()?
> 
> My preference would have been for nfs v4 to uses a directory entry count in
> the arguments, and a variable length array in the results. However, as I said
> at the bakeoff, it's probably too late for that degree of change. I suggest
> declaring dircount and maxcount as hints,  leave it to server to whether the
> hints apply to unencoded or encoded data.
> 

So let's clearly specify the protocol instead of throwing away pieces
that we didn't personally understand in favor of something worse.  The
protocol specification should as clearly as possible specify what the
various field correspond to and what units they are in.  If dircount is
a hint, then let's call it a hint and tell implementators that it is
units of XDR encoded dirents, where a dirent is a name, fileid, and a
cookie for the next entry in the directory.  The maxcount appears to be
a count of the maximum size of the XDR encoded response, not including
RPC overhead.

		ps

---

From: Peter Staubach <[email-masked]>
Date: Tue, 2 Nov 1999 18:30:02 -0800 (PST)

> 
> The client makes a specific request for the filehandle with the 
> 'attr_request' field.  In the case of readdir the filehandle is 
> considered an attribute.
> 

Ahh..  that was that I should thought should happen, but I missed
the file handle in the fattr4 section after a quick perusal.

	Thanx...

		ps

---

From: Peter Staubach <[email-masked]>
Date: Tue, 2 Nov 1999 18:27:29 -0800 (PST)

> 
> > 
> > I will raise a question/poll in response.  Does anyone have a client
> > which can actually do anything valid with an NFS4ERR_BAD_COOKIE or
> > even an NFS3ERR_BAD_COOKIE?  It is not the sort of error that can be
> > handled by the client NFS implementation.  It needs to get returned
> > back to the application level in order for it to determine what
> > should be done.  There aren't any UNIX systems that I am aware that
> > can correctly a "bad cookie" error, are there any other operating
> > systems which can?
> 
> How does the server communicate the stale or bad cookie to the client?
> It needs some sort of error return.  I agree that it is difficult
> for the Unix client to deal with such an error but what is the
> server supposed to do with a bad cookie value other than return an
> error.
> 

Historically, servers (and local file systems even) have had to deal
with this sort of problem.  How do they do it now?  I don't know
because I have never bothered to look.  I just assumed that they did.
Do we need another mechanism to solve a problem which has already been
solved?

Hence, the poll.

	Thanx...

		ps

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 2 Nov 1999 19:21:47 -0800

> So, if you don't have a dircount like element, how much data should
> the server attempt to read from the directory in order to satisfy the
> READDIR request?  A lot?  A little?  Picking the wrong number can be
> dreadful, performance wise.  At least with some sort of hint, the
> server has a starting place.
  
Pick too high a number and you waste time getting directory entries
you don't use.  Pick too low a number a you eaither have to do
multiple VOP_READDIR's or return less than maxcount (which you can
do but hurts performance).

Who is best placed to pick that number given maxcount, the client
or the server?  What are the factors that govern the appropriate
length to readdir for a given request:

    a) The fixed overhead per-dirent on the server

    b) The actual form of the name (number of characters of
       each length class for UTF-8)

    c) Whether the name in the dirent is UTF-8, unicode, 
       UTF-16, UCS, etc.

    d) The alignment rules for the name

    e) The length of the fixed-size attributes returned

    f) The length of the variable-length attributes returned

For b) and f), you are going to be using recent history to
come up with a guess.  Both the client and the server could
do this.

The client and server both know e).

Only the server knows a), c), and d).  The client can guess 
but will often be wrong.

So, as far as I can see, any value that the client can come 
up with for dircount, the server can do at least as well
and probably a lot better.  I don't see why the client 
should send its guess to the server or why the server
would use it.

---

From: Peter Staubach <[email-masked]>
Date: Wed, 3 Nov 1999 08:50:47 -0800 (PST)

> do but hurts performance).

That sums it up pretty well.

> should send its guess to the server or why the server

Having actually implemented a client and server, I don't agree with
this assessment.  The interesting figure here is the number of bytes of
directory information that the client is interested in getting.  This
is determined from an actual system call made from an application.  By
removing dircount, the client would need to perform some sort of
transformation on the value from the system call to discover maxcount.
The server would then need to perform another sort of transformation,
basically the reverse transformation, in order to discover an
approximate value to use for VOP_READDIR like operations.  Instead of
making everyone do these vague calculations, why not just pass the
(possibly vague) hint and skip all of the cycle burning overhead?
As long as everyone understand what they arguments are, what they
represent, and what units they are, is there really a problem that
they don't solve?

	Thanx...

		ps

---

From: Pradeep Suryanarayan <[email-masked]>
Date: Thu, 4 Nov 1999 04:14:55 -0800

This doesnt exactly concern V4, but we are running into some problems with
fileids. How important is fileids to NFS V2, V3 clients? Would it be OK if
we were to return a bogus fileid?

Thanks,
  - Pradeep.

-----Original Message-----
From: Brent [mailto:[email-masked]]
Sent: Thursday, November 04, 1999 2:11 AM
To: [email-masked]
Subject: Re: READDIR cleanup

"Noveck, Dave" wrote:
> How about defining dircount in terms of the number of bytes of
> directory information in nfs's over-the-wire format.  This
> would be like maxcount but all of the bytes devoted to attribute
> information would be excluded.
> 
> This wouldn't be an exact match for any particular client or
> for any particular server, but it would be pretty close in
> most cases.  The advantage would be that it is something the
> spec can clearly define so everybody has the same understanding.

Sounds like a good argument for doing it all with maxcount.

If the client starts with its opinion of dircount, then adds
in all the bytes for attribute information, it'll have
maxcount.

	Brent

---

From: Peter Staubach <[email-masked]>
Date: Thu, 4 Nov 1999 09:33:00 -0800 (PST)

> we were to return a bogus fileid?

Fileids are extremely important to some NFS clients.  (I can't speak for
all of them, just all that I have seen...)  However, as long as they
consistent, ie. the same file on the server always appears to have the
same fileid, and they fit into the over the wire element, then life is
good.

If the fileids aren't consistent, then things like "pwd" won't work
correctly.  This would be considered bad.  :-)

		ps