From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 13:24:11 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 8E9871065673; Sun, 21 Aug 2011 13:24:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 316648FC16; Sun, 21 Aug 2011 13:24:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAIoGUU6DaFvO/2dsb2JhbABBDoQ9pD2BQAEBAQEDAQEBICsgCxsYAgINGQIpAQkmBggHBAEaAgSHVKUCkDWBLIQMgRAEkQaCDpA+VA X-IronPort-AV: E=Sophos;i="4.68,258,1312171200"; d="scan'208";a="131746198" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 21 Aug 2011 09:24:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 26795B3F08; Sun, 21 Aug 2011 09:24:10 -0400 (EDT) Date: Sun, 21 Aug 2011 09:24:10 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: pjd@freebsd.org, 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: Sun, 21 Aug 2011 13:24:11 -0000 Benjamin Kaduk wrote: > On Sat, 20 Aug 2011, Rick Macklem wrote: > > >> Yes, using vfs_getnewfsid() does not solve the issue. > >> > >> I noticed that Solaris looked up a fixed array vfssw[] exactly for > >> the purpose. I think a table like it is a good solution for fixing > >> fsid for each file system. > >> > >> -- Hiroki > > If anyone thinks using a fixed table to assign vfc_typenum for known > > file system types is a bad idea, please let us know. > > Fixed table sounds like a good plan. > Is there a reason for/against using a hash table for types that are > not in > the fixed table? The advantage would be that out-of-tree filesystems > get > a consistent typenum (modulo hash collisions), but there would be more > overhead in maintaining the table. > Well, the current code maintains maxvfsconf as the largest value of vfc_typenum configured. (vfs_register() increases it and vfs_unregister() shrinks it back down.) Then, vfs_sysctl() returns maxvfsconf for a sysctl. I don't know what uses that sysctl, but it seems that doing a hash on vfc_name (which I think was what you were suggesting?) would result in a large maxvfsconf with sparsely distributed vfc_typenum values. I don't know, but I suspect that wouldn't satisfy the desired sysctl() behaviour? rick > -Ben Kaduk > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"