From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 08:21:24 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 19325106564A; Wed, 24 Aug 2011 08:21:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8DAE68FC12; Wed, 24 Aug 2011 08:21:23 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7O8LJLR030301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 11:21:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p7O8LJU7054860; Wed, 24 Aug 2011 11:21:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7O8LJp4054859; Wed, 24 Aug 2011 11:21:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Aug 2011 11:21:19 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> References: <20110823151041.GA1697@garage.freebsd.pl> <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> <20110823212301.GE1697@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sm8tznmXhqMF9oN0" Content-Disposition: inline In-Reply-To: <20110823212301.GE1697@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Benjamin Kaduk , Rick Macklem , 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 08:21:24 -0000 --Sm8tznmXhqMF9oN0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > Pawel Jakub Dawidek wrote: > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > > > > Ok, I'll admit I wasn't very fond of a fixed table that would > > > > inevitably > > > > get out of date someday, either. > > > > > > > > I didn't think hashing for the cases not in the table was worth the > > > > effort, > > > > but doing a hash instead of a table seems reasonable. > > > > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and come > > > > up > > > > with an 8bit hash solution and will post a patch for testing/review > > > > soon. > > > > > > > > I don't think the vfs_sysctl() is that great a concern, given that > > > > it > > > > appears to be deprecated already anyhow. (With an 8bit hash, > > > > vfs_typenum > > > > won't be that sparse.) I'll also make sure that whatever hash I use > > > > doesn't collide for the current list of file names (although I will > > > > include > > > > code that handles a collision in the patch). > > >=20 > > > Sounds great. Thanks! > > >=20 > > Here's the patch. (Hiroki could you please test this, thanks, rick.) > > ps: If the white space gets trashed, the same patch is at: > > http://people.freebsd.org/~rmacklem/fsid.patch >=20 > The patch is fine by me. Thanks, Rick! Sorry, I am late. It seems that the probability of the collisions for the hash is quite high. Due to the fixup procedure, the resulting typenum will depend on the order of the module initialization, isn't it ? IMO, it makes the patch goal not met. --Sm8tznmXhqMF9oN0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5UtH4ACgkQC3+MBN1Mb4hWpwCghA4kC9ojHrWXH5hlBZyYbdk+ DncAni6QrkO3EihSbIoDaT1aFjt4Gmqt =Fh7T -----END PGP SIGNATURE----- --Sm8tznmXhqMF9oN0--