From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 19:13:37 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3ECD106564A; Wed, 24 Aug 2011 19:13:37 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D98F8FC12; Wed, 24 Aug 2011 19:13:36 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OJDMSA085253; Thu, 25 Aug 2011 04:13:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OJDJbX048186; Thu, 25 Aug 2011 04:13:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 25 Aug 2011 04:13:15 +0900 (JST) Message-Id: <20110825.041315.156163335542976067.hrs@allbsd.org> To: rmacklem@uoguelph.ca From: Hiroki Sato In-Reply-To: <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> References: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Aug_25_04_13_15_2011_895)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Thu, 25 Aug 2011 04:13:34 +0900 (JST) X-Spam-Status: No, score=-104.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: kostikbel@gmail.com, pjd@FreeBSD.org, kaduk@MIT.EDU, current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:13:37 -0000 ----Security_Multipart(Thu_Aug_25_04_13_15_2011_895)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca>: rm> Kostik Belousov wrote: rm> > On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: rm> > > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: rm> > > > Pawel Jakub Dawidek wrote: rm> > > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: rm> > > > > > Ok, I'll admit I wasn't very fond of a fixed table that would rm> > > > > > inevitably rm> > > > > > get out of date someday, either. rm> > > > > > rm> > > > > > I didn't think hashing for the cases not in the table was rm> > > > > > worth the rm> > > > > > effort, rm> > > > > > but doing a hash instead of a table seems reasonable. rm> > > > > > rm> > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and rm> > > > > > come rm> > > > > > up rm> > > > > > with an 8bit hash solution and will post a patch for rm> > > > > > testing/review rm> > > > > > soon. rm> > > > > > rm> > > > > > I don't think the vfs_sysctl() is that great a concern, given rm> > > > > > that rm> > > > > > it rm> > > > > > appears to be deprecated already anyhow. (With an 8bit hash, rm> > > > > > vfs_typenum rm> > > > > > won't be that sparse.) I'll also make sure that whatever hash rm> > > > > > I use rm> > > > > > doesn't collide for the current list of file names (although I rm> > > > > > will rm> > > > > > include rm> > > > > > code that handles a collision in the patch). rm> > > > > rm> > > > > Sounds great. Thanks! rm> > > > > rm> > > > Here's the patch. (Hiroki could you please test this, thanks, rm> > > > rick.) rm> > > > ps: If the white space gets trashed, the same patch is at: rm> > > > http://people.freebsd.org/~rmacklem/fsid.patch rm> > > rm> > > The patch is fine by me. Thanks, Rick! rm> > rm> > Sorry, I am late. rm> > rm> > It seems that the probability of the collisions for the hash is quite rm> > high. rm> > Due to the fixup procedure, the resulting typenum will depend on the rm> > order rm> > of the module initialization, isn't it ? IMO, it makes the patch goal rm> > not rm> > met. rm> Well, the about 15 file system types currently in FreeBSD don't collide. rm> (At least with the patch I posted. I'll test it again with "hash & 0xff;".) rm> rm> Also, since the collision results in the second one using the next higher rm> value (usually, until you get something like 50+ file system types), it works rm> for those cases unless the order that these 2 file systems call vfs_register() rm> is reversed. (The likelyhood of this reversal is lower than the likelyhood rm> of vfs_register() just being called in a different order, I think?) rm> rm> Since it now changes whenever a different kernel config or different module rm> loading order is used and there aren't a lot of complaints, I think "usually rm> works" is good enough. However, it doesn't matter to me, so I'll let others rm> decide. rm> rm> Yet another option is to go back to what hrs@ originally suggested, which rm> was change ZFS to not use vfc_typenum in its fsid. (I now see that 0 won't rm> conflict with any assigned vfc_typenum values, since they start at 1 and rm> 255 would also probably be safe, since its unlikely there ever will be rm> 255 different file system types.) The problem with this is no future FS rm> can use the same trick. 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. -- Hiroki ----Security_Multipart(Thu_Aug_25_04_13_15_2011_895)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5VTUsACgkQTyzT2CeTzy3QqgCeIJwG0uxBz3Sjg0fMUNbBmfre hjQAn1BzuAX6EeCHlg2rHuwRh8rCcmnG =WhV4 -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Aug_25_04_13_15_2011_895)----