From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 21:17:21 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 0A9E4106564A for ; Wed, 24 Aug 2011 21:17:21 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id B1A6D8FC13 for ; Wed, 24 Aug 2011 21:17:20 +0000 (UTC) X-AuditID: 12074424-b7bcaae000000a05-0c-4e556a8bcf08 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.17.02565.B8A655E4; Wed, 24 Aug 2011 17:18:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p7OLHJt8006928; Wed, 24 Aug 2011 17:17:19 -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 p7OLHHxt001649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 17:17:19 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7OLHHf2026706; Wed, 24 Aug 2011 17:17:17 -0400 (EDT) Date: Wed, 24 Aug 2011 17:17:17 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <468764384.310026.1314219682612.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+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrdudFepnsO8zp8WEKz+YLB4uu8bk wOQx49N8Fo/fm/cyBTBFcdmkpOZklqUW6dslcGUse9PEVtAlWtF58SZ7A+MxgS5GTg4JAROJ T5+fs0LYYhIX7q1n62Lk4hAS2McoMaXjChOEs4FR4u2OhYwQzgEmie1TXrNAOA2MEs8PbmcB 6WcR0Jb4cPMWG4jNJqAiMfPNRjBbREBdYvPqfmYQm1lAXOLJ7Xdg+4QFFCQm3F3HBGJzCvhL NH16A2bzCjhIrLx4DaxXSMBPYmL/IrD5ogI6Eqv3T2GBqBGUODnzCQvETEuJc3+us01gFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MoGBld1HZwdh8SOkQ owAHoxIP7wWHUD8h1sSy4srcQ4ySHExKorwrM4FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhP nQvxE+JNSaysSi3Kh0lJc7AoifPa7HTwExJITyxJzU5NLUgtgsnKcHAoSfBuBhkqWJSanlqR lplTgpBm4uAEGc4DNDwVpIa3uCAxtzgzHSJ/ilFRSpz3KEhCACSRUZoH1wtLJq8YxYFeEeZd AFLFA0xEcN2vgAYzAQ3m+BUEMrgkESEl1cCoePiCwiNWg937inUV2C4/f5hV9HbGRTPHmV4h KauUakTeqKsLvo0umtTdGJlv4DTP2UJY/2aYt1bduq0KfFW6sxVtHu/r3rPpcPmNeU8LCj8p cbxXU1zuLxnI+eOT6Uerxatueu0u2vDDLiun5Ntk1vh3k1lLRQ/9ON7AWPfv3f6Xx+rcX9so sRRnJBpqMRcVJwIAOs0FwwEDAAA= 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: Wed, 24 Aug 2011 21:17:21 -0000 On Wed, 24 Aug 2011, Rick Macklem wrote: > "afs" The current OpenAFS codebase uses the all-caps "AFS". Judging by the omitted text, perhaps this should change. (We also don't use VFS_SET to set it, which I filed a bug about.) > > and here is my current rendition of the patch. (I took Gleb's suggestion > and switched to fnv_32_str(). I'll leave it that way unless there is a > collision after adding any names people post to the above list.) > > It sounds like people have agreed that this is a reasonable solution. > If hrs@ can confirm that testing shows it fixes the original problem > (the ZFS file handles don't change when it's loaded at different times), > I'll pass it along to re@. > > Thanks for the helpful suggestions, rick > > --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 > +++ kern/vfs_init.c 2011-08-24 16:15:24.000000000 -0400 > @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in > > #include > #include > +#include > #include > #include > #include > @@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc) > struct sysctl_oid *oidp; > struct vfsops *vfsops; > static int once; > + struct vfsconf *tvfc; > + uint32_t hashval; > > if (!once) { > vattr_null(&va_null); > @@ -152,7 +155,26 @@ 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 > + * a collision occurs, it is limited to 8bits since that is > + * what ZFS uses from vfc_typenum and that also limits how sparsely > + * distributed vfc_typenum becomes. > + */ > + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); > + hashval &= 0xff; > + do { > + /* Look for and fix any collision. */ > + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { > + if (hashval == tvfc->vfc_typenum) { > + hashval++; /* Can exceed 8bits, if needed. */ 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. 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. > + 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? -Ben > TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); > > /* > > >