From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 11:46:31 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 04FC61065679; Tue, 23 Aug 2011 11:46:31 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id A9F5E8FC13; Tue, 23 Aug 2011 11:46:30 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 8FCDC9A3; Tue, 23 Aug 2011 13:31:02 +0200 (CEST) Date: Tue, 23 Aug 2011 13:30:45 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Message-ID: <20110823113044.GB1662@garage.freebsd.pl> References: <20110820.142859.319295417241413417.hrs@allbsd.org> <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) 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 11:46:31 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote: > Hiroki, could you please test the attached patch. >=20 > 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?) >=20 > 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: >=20 > printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum); >=20 > just after vfc->vfc_typenum =3D 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. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk5Tj2QACgkQForvXbEpPzSsPACgs1bUMf9f8+B3oXBuQ8iw4+Dy AKMAoKeIoNcEww/EZpfyMnTL/XuDug5x =aUbk -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP--