From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH 2/2] system: Add btrfs file system support. Date: Sat, 03 Dec 2016 16:21:58 +0100 Message-ID: <877f7havhl.fsf@gnu.org> References: <20161130183635.6513-1-david@craven.ch> <20161130183635.6513-2-david@craven.ch> <87zikfsbk3.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <87zikeposs.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDC8a-00007x-6C for guix-devel@gnu.org; Sat, 03 Dec 2016 10:22:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDC8X-0001mM-00 for guix-devel@gnu.org; Sat, 03 Dec 2016 10:22:04 -0500 In-Reply-To: <87zikeposs.fsf@gmail.com> (Chris Marusich's message of "Fri, 02 Dec 2016 03:12:51 -0800") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel Chris Marusich skribis: > David Craven writes: > >> Ludo: Is there any way we can speed up the installer system tests? :) > > I've also wondered about this. I'm not sure how long each test takes to > run, so an analysis of the tests to find their slow areas might help > guide us. I suspect that we could probably speed up the tests by using > a shared test fixture of some kind (e.g., a common store, or a base qemu > disk image [1], which could be used by multiple tests), but first we'd > need to know which part(s) are slow. Tests that use =E2=80=98system-qemu-image/shared-store-script=E2=80=99 (bas= ic, mcron, openssh, etc.) are relatively fast. However, the installation tests have to use a real (full, standalone) image for the installation disk, and also for the target disk. Otherwise we wouldn=E2=80=99t be testing the same thing. > Another possibility might be to parallelize the tests (I don't think the > system tests are done in parallel right now, even if you specify "make > -j", but someone correct me if I'm wrong), but that could be > counter-productive if it took up too many system resources. They are derivation builds, so they are performed in parallel according to --max-jobs. Thanks, Ludo=E2=80=99.