From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 23:02: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 0D97D106566C for ; Thu, 25 Aug 2011 23:02:45 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id B3CAE8FC0C for ; Thu, 25 Aug 2011 23:02:44 +0000 (UTC) X-AuditID: 1209190d-b7be0ae000000a16-15-4e56d3d549de Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 48.9C.02582.5D3D65E4; Thu, 25 Aug 2011 18:59:33 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p7PN2hAO008039; Thu, 25 Aug 2011 19:02:43 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7PN2gtq021755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Aug 2011 19:02:43 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7PN2fCM015129; Thu, 25 Aug 2011 19:02:41 -0400 (EDT) Date: Thu, 25 Aug 2011 19:02:41 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <1252487773.337126.1314285501432.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <1252487773.337126.1314285501432.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nonv1cpifwfVFshYTrvxgsni47BqT A5PHjE/zWTx+b97LFMAUxWWTkpqTWZZapG+XwJXx4NtVtoKr4hVXL+5nbGDcKNTFyMkhIWAi sf7qbjYIW0ziwr31QDYXh5DAPkaJl9Mns0A4Gxgl3k2/zQ7hHGCSuPHiOROE08Ao0Xe2A6yf RUBb4sfu54wgNpuAisTMNxvB4iIC6hKbV/czg9jMAuIST26/YwWxhQUUJCbcXQc0iIODUyBA 4vt2TZAwr4CDxIemb2BjhAT8JSb/n8QCYosK6Eis3j+FBaJGUOLkzCcsECMtJc79uc42gVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MYJClVOSdwfju4NK hxgFOBiVeHgv5oT5CbEmlhVX5h5ilORgUhLl7QQGuhBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3uZQoBxvSmJlVWpRPkxKmoNFSZy3cIeDn5BAemJJanZqakFqEUxWhoNDSYL3FMhQwaLU9NSK tMycEoQ0EwcnyHAeoOE+IDW8xQWJucWZ6RD5U4yKUuK8M0ESAiCJjNI8uF5YKnnFKA70ijDv bpAqHmAagut+BTSYCWgwx68gkMEliQgpqQbGpez+DM/lJFez/fzrznRHzcaqvznuqH5I6evv F6VUdG7+Z09zsO2ef7rn3wPnc7IxdSvKG/nWv/O1fPuG9bPKqatlh3zfXfbebllve+/hn+Ib boH3XnvfcDGYa2Bq1G2vcFIsR/pB0cKmqt93/gsIL59dpvx0zuRH5Rp33DgEDdOzN/Q3f3RW YinOSDTUYi4qTgQAfL7SmwADAAA= Cc: 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: Thu, 25 Aug 2011 23:02:45 -0000 On Thu, 25 Aug 2011, Rick Macklem wrote: > Benjamin Kaduk wrote: >> >> If we're confident that we won't ever fully fill the hash table, I >> would >> think that this should wrap around back to zero (or one?) instead of >> overflowing. >> > Here's my updated patch (it will wrap to 1 the first time and then > exceed 255 if 1<->255 are all in use). > --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 > +++ kern/vfs_init.c 2011-08-25 11:09:14.000000000 -0400 > @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in > > #include > #include > +#include > #include > #include > #include > @@ -138,6 +139,9 @@ vfs_register(struct vfsconf *vfc) > struct sysctl_oid *oidp; > struct vfsops *vfsops; > static int once; > + struct vfsconf *tvfc; > + uint32_t hashval; > + int secondpass; > > if (!once) { > vattr_null(&va_null); > @@ -152,7 +156,31 @@ vfs_register(struct vfsconf *vfc) > if (vfs_byname(vfc->vfc_name) != NULL) > return EEXIST; > > - vfc->vfc_typenum = maxvfsconf++; > + /* > + * Calculate a hash on vfc_name to use for vfc_typenum. Unless > + * all of 1<->255 are assigned, it is limited to 8bits since that is > + * what ZFS uses from vfc_typenum and is also the preferred range > + * for vfs_getnewfsid(). > + */ > + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); > + hashval &= 0xff; > + secondpass = 0; > + do { > + /* Look for and fix any collision. */ > + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { > + if (hashval == tvfc->vfc_typenum) { > + if (hashval == 255 && secondpass == 0) { > + hashval = 1; > + secondpass = 1; > + } else > + hashval++; > + break; > + } > + } > + } while (tvfc != NULL); > + vfc->vfc_typenum = hashval; > + if (vfc->vfc_typenum >= maxvfsconf) > + maxvfsconf = vfc->vfc_typenum + 1; > TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); > > /* > >> Do we need to care about something attempting to add the same vfc_name >> twice? This code will happily add a second entry at the next available >> index. >> > If file systems use VFS_SET(), I don't think this can happen, since the > same vfc_name would imply "same module name" and the 2nd one wouldn't load. > (Been there, w.r.t. nfs.) Ah. I guess I should get my act together and use VFS_SET, then. *hangs head sheepishly* > >>> + break; >>> + } >>> + } >>> + } while (tvfc != NULL); >>> + vfc->vfc_typenum = hashval; >>> + if (vfc->vfc_typenum >= maxvfsconf) >>> + maxvfsconf = vfc->vfc_typenum + 1; >> >> I guess we're holding off on killing maxvfsconf until after 9.0 is >> out? > > Well, I still don't know if anything has a use for vfs_sysctl(), so > I'm not volunteering to take it out. (If others feel it should come > out for 9.0, maybe... But I would still consider that a separate patch.) I don't particularly have an axe to grind, Danish or otherwise. Thanks for the update, Ben