Date: Wed, 24 Aug 2011 15:24:48 -0400 (EDT) From: Benjamin Kaduk <kaduk@MIT.EDU> To: Hiroki Sato <hrs@freebsd.org> Cc: kostikbel@gmail.com, rmacklem@uoguelph.ca, pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? Message-ID: <alpine.GSO.1.10.1108241522000.7526@multics.mit.edu> In-Reply-To: <20110825.041315.156163335542976067.hrs@allbsd.org> References: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> <20110825.041315.156163335542976067.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 Aug 2011, Hiroki Sato wrote: > > My opinion is using a hash function which occurs no collision in the > well-known names is sufficient for our purpose because the number of > file systems on a running system is small anyway and not changed > frequently in most cases. I am not sure which function is best; > fnv_32_str() seemed better against a large data set but it is not > likely to have >30 file systems, for example. This was a large part of my reasoning when proposing a hash table initially -- there are 256 (maybe 255 if you want to reserve one) slots, and only 14 or so filesystems currently in the tree. It seems very unlikely that any single machine would ever have more than another five out-of-tree filesystem types on it (right?), so putting 20 items into 250 hash bins is a pretty good chance of being collision-free. -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1108241522000.7526>