>  > But there is no reason why it shouldn't optimise for what it expects to
>  > see most often....
> 
> And what would that be?  Solaris?  NetBSD?  Tru64?

This is NFS, all the implementations are clones of each other,
I'd guess that there is little difference between the implementations.

In any case the remote system can subvert your hashing system by 'careful'
choice of values whatever you use, file handles are in no way 'random'.

Actually, given we are talking of NFS here - where is this hashing?
The only place I can think of is the client assigning responses to
outstanding requests.
In which case do the lookup by request id! which means (1) the client is#
in control of the lookup vale and (2) only a limited number of values (the
concurrent outstanding requests) need to be searched through.
What was the test that required a search through 40000 items?

One note about the stats given, is that although the hash lists were
much more even, the total time for the test was largely unchanged!
This surely means that either (1) the time spent in this lookup is
completely insignificant or (2) the cost of the 'new improved hash'
function completely overwhelms the 'benefit' of reducing the length
of the hash chains.  In either case the proposed change is of no (real)
benefit.

    David