From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 14:09:44 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 D6609106567B; Tue, 23 Aug 2011 14:09:44 +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 5D07A8FC0A; Tue, 23 Aug 2011 14:09:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAF20U06DaFvO/2dsb2JhbABBhEukSIFAAQEFIwQuJBsYAgINGQJZBi6wXJF+gSyEDIEQBJMZkRY X-IronPort-AV: E=Sophos;i="4.68,269,1312171200"; d="scan'208";a="135261448" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 23 Aug 2011 10:09:41 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 23DAAB3F2A; Tue, 23 Aug 2011 10:09:41 -0400 (EDT) Date: Tue, 23 Aug 2011 10:09:41 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <1965813445.219973.1314108581091.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110823113044.GB1662@garage.freebsd.pl> 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: Hiroki Sato , current@FreeBSD.org, Benjamin Kaduk 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: Tue, 23 Aug 2011 14:09:45 -0000 Pawel Jakub Dawidek wrote: > On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote: > > Hiroki, could you please test the attached patch. > > > > One problem with this patch is that I don't know how to create a > > fixed > > table that matches what systems would already have been getting. > > (I got the first 6 entries by booting a GENERIC i386 kernel with a > > printf in vfs_init(), so I suspect those don't change much, > > although > > I'm not sure if ZFS will usually end up before or after them?) > > > > Do you guys know what ZFS gets assigned typically? (I realize that > > changes w.r.t. when it gets loaded, so the question also becomes > > "do you know how it typically gets loaded" so the table can have > > that vfc_typenum value assigned to it?) > > Maybe you could boot a system with a printf like: > > > > printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum); > > > > just after vfc->vfc_typenum = maxvfsconf++; in vfs_init() and > > then look in dmesg after booting, to see what your tables look like? > > (Without the attached patch installed.) > > Rick, I'm sorry to arrive so late, but in my opinion hardcoding list > of > file systems in the kernel is a step in wrong direction, really. > We are trying to keep things modularized, so there are no such things > laying around that have to be cleaned up when file system goes away or > updated when new file system arrives. > > I remember for example fts code where I found that it keeps list of > file > systems that can be handled faster. ZFS could have been handled > faster, > but I found this after few years. > For this case there should be VFCF_* flag that fts shuld recognize and > not > hardcore file system names. > > This was also the reason that when I added support for "jail-friendly" > file systems and support for file systems with delegated > administration > I haven't created list of file system types that support it, but added > VFCF_JAIL and VFCF_DELEGADMIN flags. > > Here you cannot use those flags to solve the problem, but hardcoding > file system types in an array is really not the way to go. > > I much prefer Ben's idea of calculating a hash from file system name > and > detecting collisions. > Ok, I'll admit I wasn't very fond of a fixed table that would inevitably get out of date someday, either. I didn't think hashing for the cases not in the table was worth the effort, but doing a hash instead of a table seems reasonable. I see that ZFS only uses the low order 8 bits, so I'll try and come up with an 8bit hash solution and will post a patch for testing/review soon. I don't think the vfs_sysctl() is that great a concern, given that it appears to be deprecated already anyhow. (With an 8bit hash, vfs_typenum won't be that sparse.) I'll also make sure that whatever hash I use doesn't collide for the current list of file names (although I will include code that handles a collision in the patch). Thanks for the comments, rick > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com