From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 04:27:28 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 DB1F0106566B; Mon, 22 Aug 2011 04:27:27 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9708FC12; Mon, 22 Aug 2011 04:27:27 +0000 (UTC) X-AuditID: 12074423-b7b31ae000000a3c-45-4e51daaf0916 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.A7.02620.FAAD15E4; Mon, 22 Aug 2011 00:27:27 -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 p7M4RQRL023740; Mon, 22 Aug 2011 00:27:26 -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 p7M4RNuE004056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Aug 2011 00:27:25 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7M4RNUg012621; Mon, 22 Aug 2011 00:27:23 -0400 (EDT) Date: Mon, 22 Aug 2011 00:27:23 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <917325587.123830.1313933050111.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+NgFvrMIsWRmVeSWpSXmKPExsUixG6norv+VqCfwZk/GhYTrvxgsrg8dSmb xcNl15gcmD1mfJrP4vF7816mAKYoLpuU1JzMstQifbsEroyu13OYCxYJVFy+fJu5gfETTxcj J4eEgInE9XWtrBC2mMSFe+vZuhi5OIQE9jFKnN/wlBHC2cAo8WXPPyjnAJPE7MNboJwGRokD n56ygfSzCGhL/Lt0gwXEZhNQkZj5ZiNYXERAXWLz6n5mEJtZQEOi4eRMsLiwgILEhLvrmEBs TgF/ie6XS8BqeAUcJHZ3N4DZQgJ+Eq9294DdJyqgI7F6/xQWiBpBiZMzn7BAzLSUOPfnOtsE RsFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECA5bF+UdjH8O Kh1iFOBgVOLhfWAS6CfEmlhWXJl7iFGSg0lJlHfzVaAQX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed6elUA53pTEyqrUonyYlDQHi5I4r8xOBz8hgfTEktTs1NSC1CKYrAwHh5IE74ebQI2CRanp qRVpmTklCGkmDk6Q4TxAw8+A1PAWFyTmFmemQ+RPMSpKifMeBUkIgCQySvPgemFp5RWjONAr wrwvQap4gCkJrvsV0GAmoMETVgaADC5JREhJNTCmMHKmT2u4Xyfz1ujnLHP/q2+kAytfla58 1xKWIfg2bLn1w8ULijhk1zO/eHI+3Wc+54a+jAdn7Ly9zBkDt9qc0Jn9OPsvzySfmQc7Z2o+ +H93EtvP+N9ZrYtO/jm27KOhyr795xMr2v6/T9DQ3rrrxOoXjn2HIzmVHfnz17yeFSNelfA5 nuW8EktxRqKhFnNRcSIAho3BAgYDAAA= 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 04:27:28 -0000 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. > 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. -Ben