From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 13:15:34 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 9843B106566B; Mon, 22 Aug 2011 13:15:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 397A78FC12; Mon, 22 Aug 2011 13:15:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPRVUk6DaFvO/2dsb2JhbABBDoQ9pDeBQAEBAQECAQEBASAEJyALGxgCAg0ZAikBCSYGCAcEARwEh1AEpBaQeIEshAyBEASRBoIOkD9U X-IronPort-AV: E=Sophos;i="4.68,263,1312171200"; d="scan'208";a="135134454" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 Aug 2011 09:15:33 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2DC59B3F27; Mon, 22 Aug 2011 09:15:33 -0400 (EDT) Date: Mon, 22 Aug 2011 09:15:33 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <1581074997.148660.1314018933175.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: Mon, 22 Aug 2011 13:15:34 -0000 Benjamin Kaduk wrote: > On Sun, 21 Aug 2011, Rick Macklem wrote: > > > Benjamin Kaduk wrote: > >> On Sat, 20 Aug 2011, Rick Macklem wrote: > >> > >>> 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.) > > Yes; I assume this is just so that it can keep track of how to > efficiently > allocate an id to the next filesystem that is registered. It still > walks > the whole list in vfs_unregister, though, so there is some amount of > overhead involved. > > > > > Then, vfs_sysctl() returns maxvfsconf for a sysctl. I don't know > > what uses > > vfs_sysctl() also starts off with: > printf("WARNING: userland calling deprecated sysctl, " > "please rebuild world\n"); > I don't know where (if anywhere) it is legitimately used, but it is > plausible that it could safely be deprecated. > If/what might use this sysctl is my main concern w.r.t. the patch. (Even without using a hash, the table will result in some gaps in the assignment of vfc_typenum and the sysctl will return ENOTSUPP for those. If a program is looping through them all, from 0<->maxvfsconf it would need to ignore those.) I'm going to grep /usr/src for any use(s) of it, but I don't know beyond that. > > 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? > > I don't think tracking maxvfsconf would be useful with a hash table > approach -- fxr seems to indicate that it is only used so as to give a > unique number to a new filesystem, and a hash table with collision > detection could perform that role. > > But, I don't have a good assessment of the tradeoffs involved. It may > not > be worth the code churn just for the sake of a couple of out-of-tree > filesystems that never get exported over NFS; I just don't know. > At this point in the 9.0 release cycle, I'd lean towards less churn and preserving the sysctl(), except that it would still have some small gaps in it. (As you say, there aren't a lot of file system types that will be NFS exported anyhow.) How do others feel w.r.t. this? W.r.t what file system types get exported over NFS... - I think the current list might be: ufs, zfs, msdosfs, cd9660, udf Does anyone out there NFS export any others? rick > -Ben > _______________________________________________ > 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"