test hash functions for fsid
cem at freebsd.org
Thu May 9 22:01:26 UTC 2019
On Thu, May 9, 2019 at 2:44 PM Rick Macklem <rmacklem at uoguelph.ca> wrote:
> I do now think I can dynamically size it based on how many file systems
> (which is how many structures) will be linked off the table, so this shouldn't be
> a problem.
> >Load factor is just number of valid entries divided by space in the
> >table. So if your table has 256 spaces, load factor 0.8 would be
> >having about 205 valid entries.
> Hmm. That would suggest a large table size of about 100,000 for Peter's
> 72,000 file system case. It would result in a list length averaging about 1 entry,
Yeah, that's usually how hash tables are sized — aiming for a list
length of 1 (for chaining hash tables) or relatively short probe
sequence (for open addressing / embedded entry tables). It's what
provides the various "O(1)" properties hash tables ostensibly have.
> but I think a linear search through 10-20 entries won't take long enough to be
> a problem for this case. (This happens whenever mountd receives a SIGHUP and each time a client does a mount.)
Yes, it might not be noticeable in this application either way.
> As noted in the last post, I was thinking along the lines of 10->20 as a target
> linked list length. (Or "table_size = num / L", where L is the target average list length.
> L = 10->20 would be roughly a load average of 10->20.)
> Does that sound reasonable? (Interested in hearing from anyone on this.)
Wikipedia discusses it a little bit:
Facebook recently open sourced their general-purpose C++ hashtable
implementations and talk at length about various tradeoffs, including
load: https://code.fb.com/developer-tools/f14/?r=1 It might be
interesting to read.
Anyway, usually it's a number less than 1. 10-20x is unconventional.
> Yes. It would be the distribution of values and not their randomness that would
> matter for this case. Hopefully someone with a large # of UFS file systems will
> run the test program and post the results. To be honest, I doubt if anyone will
> create a server with enough UFS file systems for it to be important to hash their
> fsid well. It works fine for the small number of UFS file systems I have.)
Maybe pho@ will take that as a challenge. You could create a lot of
UFS filesystems with mdconfig and enough RAM.
> Thanks for the comments, rick
More information about the freebsd-fs