From: Noveck, Dave (dave.noveck@netapp.com)
Date: 11/02/99-09:21:47 PM Z
Message-ID: <4080CE03B682D311B589009027C2286638D32D@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: READDIR cleanup
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.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:47 AM Z CST