From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 21:30:45 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 3541A106564A; Thu, 25 Aug 2011 21:30:45 +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 519AF8FC12; Thu, 25 Aug 2011 21:30:42 +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 p7PLUQ0I071784; Fri, 26 Aug 2011 06:30:36 +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 p7PLUNk5062670; Fri, 26 Aug 2011 06:30:25 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 26 Aug 2011 06:30:17 +0900 (JST) Message-Id: <20110826.063017.934842008473299966.hrs@allbsd.org> To: rmacklem@uoguelph.ca From: Hiroki Sato In-Reply-To: <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca> References: <20110824200813.GC1688@garage.freebsd.pl> <468764384.310026.1314219682612.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(Fri_Aug_26_06_30_17_2011_258)--" 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]); Fri, 26 Aug 2011 06:30:38 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, 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, current@FreeBSD.org, kaduk@MIT.EDU 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: Thu, 25 Aug 2011 21:30:45 -0000 ----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca>: rm> Pawel Jakub Dawidek wrote: rm> > On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote: rm> > > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: rm> > > > Well, doesn't this result in the same issue as the fixed table? rm> > > > In other words, the developer has to supply the "suggested byte" rm> > > > for rm> > > > fsid and make sure that it doesn't conflict with other "suggested rm> > > > byte" rm> > > > values or suffer the same consequence as forgetting to update the rm> > > > fixed rm> > > > table. (ie. It just puts the fixed value in a different place, rm> > > > from what rm> > > > I see, for in-tree modules. Also, with a fixed table, they are all rm> > > > in rm> > > > one place, so it's easy to choose a non-colliding value?) rm> > > The reason for my proposal was Pawel note that a porter of the rm> > > filesystem rm> > > should be aware of some place in kern/ where to register, besides rm> > > writing rm> > > the module. rm> > rm> > Well, he has to be aware, but we should do all we can to minimize the rm> > number of place he needs to update, as it is easy to forget some. rm> > rm> > I agree with Rick that what you proposed is similar to fixed table of rm> > file system names and I'd prefer to avoid that. If we can have rm> > name-based hash that produces no collision for in-tree file systems rm> > and rm> > know current 3rd party file systems plus collision detection for the rm> > future then it is good enough, IMHO. And this is what Rick proposed rm> > with rm> > his patch. rm> > rm> Ok, here is the list of file system names I've been checking and there rm> haven't been any collisions (either hash function). If you know of other rm> well known file type names, please email and I'll add them to the list rm> and check for collisions again. rm> rm> "cd9660" rm> "ufs" rm> "procfs" rm> "devfs" rm> "msdosfs" rm> "nfs" rm> "xfs" rm> "reiserfs" rm> "tmpfs" rm> "hpfs" rm> "ntfs" rm> "ext2fs" rm> "udf" rm> "zfs" rm> "afs" rm> rm> and here is my current rendition of the patch. (I took Gleb's suggestion rm> and switched to fnv_32_str(). I'll leave it that way unless there is a rm> collision after adding any names people post to the above list.) rm> rm> It sounds like people have agreed that this is a reasonable solution. rm> If hrs@ can confirm that testing shows it fixes the original problem rm> (the ZFS file handles don't change when it's loaded at different times), rm> I'll pass it along to re@. Thank you! I will try the latest patch by Saturday. -- Hiroki ----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5WvukACgkQTyzT2CeTzy1MBwCgiwegt+ORXMY7/dz0GwP9v2k0 eKkAn1nlk7i8JUvvyTK+i0mE4huKcffa =Onxk -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)----