The following reply was made to PR kern/35253; it has been noted by GNATS.

From: Elad Efrat <elad@NetBSD.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/35253
Date: Tue, 26 Dec 2006 12:08:52 +0200

 YAMAMOTO Takashi wrote:
 >> YAMAMOTO Takashi wrote:
 >>>> we can do something like this:
 >>>>
 >>>> 	fileassoc_table_size(struct mount *mp);
 >>>> 		return number of slots table for 'mp' was optimized for.
 >>>>
 >>>> 	fileassoc_table_optimize(struct mount *mp, size_t nentries);
 >>>> 		optimize the hash-table for 'mp' for 'nentries' slots.
 >>>>
 >>>> notes:
 >>>>   - there should be locking implications to fileassoc_table_optimize(),
 >>>>   - the wording avoids exposing internal implementation details of
 >>>>     fileassoc(9).
 >>>>
 >>> it's better to just remove fileassoc_table_add from API
 >>> and just do them internally, IMO.
 >> you mean, when a file entry is added, create the table if it's not
 >> already there?
 > 
 > yes, and resize hash appropriately according to the number of entries.
 
 on each addition? :)
 
 maybe we can add some "barriers", to intelligently resize the table...
 
 -e.