Date: Fri, 26 Aug 2011 06:30:17 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: rmacklem@uoguelph.ca Cc: kostikbel@gmail.com, pjd@FreeBSD.org, current@FreeBSD.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? Message-ID: <20110826.063017.934842008473299966.hrs@allbsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem <rmacklem@uoguelph.ca> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110826.063017.934842008473299966.hrs>