RE: READDIR cleanup

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Noveck, Dave (dave.noveck@netapp.com)
Date: 11/03/99-01:22:59 PM Z 

Message-ID: <4080CE03B682D311B589009027C2286638D331@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: READDIR cleanup
Date: Wed, 3 Nov 1999 11:22:59 -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).
> > 
> 
> That sums it up pretty well.
> 
> > 
> > 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.
> > 
> 
> 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?
 
That is just the problem, everyone doesn't understand what the
arguments mean.  The client knows what he means, that he wants no 
more than n bytes of directory information when that information
is stored in a particular format that he knows.  The server has no
idea what that format is.

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.

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:49 AM Z CST