From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 25 13:53:07 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D1F91065672 for ; Thu, 25 Feb 2010 13:53:07 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 928B58FC1B for ; Thu, 25 Feb 2010 13:53:06 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o1PDr4Tf025140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Feb 2010 14:53:04 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o1PDr3fq025137; Thu, 25 Feb 2010 14:53:04 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Thu, 25 Feb 2010 14:53:03 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: David Naylor Message-ID: <20100225135303.GM57731@acme.spoerlein.net> Mail-Followup-To: David Naylor , freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on acme.spoerlein.net Cc: freebsd-hackers@FreeBSD.org Subject: Re: [Proof of Concept] Stacked unionfs based 'tinderbox' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 13:53:07 -0000 On Thu, 25.02.2010 at 10:08:15 +0200, David Naylor wrote: > Hi, > > As some may have noticed on -current I have been working on using > stacked unionfs to implement a 'tinderbox' type build system. I have > successfully used the scripts to build x11/xorg (and have compared the > results to using the traditional approach using pkg_add). The build > system is stable except for one nasty corner case: deadlocks. When I did this a couple of years ago, the major problems were failing chdir(2) calls during ports build, etc. > To setup a compatible test environment requires: > - recompile the kernel with `options KSTACK_PAGES=32`, otherwise the > kernel will panic with a double fault. WITNESS options results in > substantial performance degradation. > - patch mtree (see below) [optional] > - create the appropriate chroot environment (and reboot) [see below > for corner case] > > A performance bottleneck in mtree was identified. This resulted in > mtree (as run by port install) consuming ~20% of the build time. See > bin/143732 for a patch and further details. Good work! > The normal tinderbox approach takes ~80% more time to install compared to the > quick and dirty approach. The stacked unionfs approach takes ~170% more time > (an increase of ~50% over the tinderbox approach). Some performance gains can > be had if one uses memory backed storage (vs HDD in this case). Please explain: what is the quick and dirty approach and which one is faster now? As your scripts did not make it through, perhaps you can upload them to the wiki? What I did back then was using a clean base system as the underlying unionfs store to avoid re-generating the clean base over and over again. Nowadays, a ZFS clone would probably be the way to go. I'm not sure if a recursive approach is feasible here, as you can have only one underlying unionfs mount. But special casing, e.g., perl may still give a massive speedup. So for each port that has perl as dependancy, you would not pull in the clean base + pkg_add perl, but instead grab the clean-base+perl directory as an underlying unionfs. Cheers Uli