Date: Wed, 24 Aug 2011 09:24:54 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Kostik Belousov <kostikbel@gmail.com> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, Benjamin Kaduk <kaduk@MIT.EDU>, current@freebsd.org Subject: Re: fsid change of ZFS? Message-ID: <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote: > 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). > > > > > > > > Sounds great. Thanks! > > > > > > > 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 > > > > 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. Well, the about 15 file system types currently in FreeBSD don't collide. (At least with the patch I posted. I'll test it again with "hash & 0xff;".) Also, since the collision results in the second one using the next higher value (usually, until you get something like 50+ file system types), it works for those cases unless the order that these 2 file systems call vfs_register() is reversed. (The likelyhood of this reversal is lower than the likelyhood of vfs_register() just being called in a different order, I think?) Since it now changes whenever a different kernel config or different module loading order is used and there aren't a lot of complaints, I think "usually works" is good enough. However, it doesn't matter to me, so I'll let others decide. Yet another option is to go back to what hrs@ originally suggested, which was change ZFS to not use vfc_typenum in its fsid. (I now see that 0 won't conflict with any assigned vfc_typenum values, since they start at 1 and 255 would also probably be safe, since its unlikely there ever will be 255 different file system types.) The problem with this is no future FS can use the same trick.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?920337541.272757.1314192294772.JavaMail.root>