GNU bug report logs - #32600
‘guix system vm-image’ spends a very long time “registering closures”

Previous Next

Package: guix;

Reported by: ludo <at> gnu.org (Ludovic Courtès)

Date: Fri, 31 Aug 2018 10:08:02 UTC

Severity: important

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: ludo <at> gnu.org (Ludovic Courtès)
Subject: bug#32600: closed (Re: bug#32600: ‘guix
 system vm-image’ spends a very long time
 “registering closures”)
Date: Sun, 23 Sep 2018 21:39:03 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#32600: ‘guix system vm-image’ spends a very long time “registering closures”

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 32600 <at> debbugs.gnu.org.

-- 
32600: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32600
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: ludo <at> gnu.org (Ludovic Courtès)
To: 32600-done <at> debbugs.gnu.org
Cc: Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#32600: ‘guix system vm-image’ spends a very long time “registering closures”
Date: Sun, 23 Sep 2018 23:38:03 +0200
Hello,

ludo <at> gnu.org (Ludovic Courtès) skribis:

> A couple of days ago, Leo reported that ‘guix system vm-image’ spends a
> very long time in the “registering closures” phase:

> <lfam> Created a bare-bones VM takes ~90 minutes for me recently

As of commit fce225471128c4a5246342b3aa1b7e53a8066211, ‘guix system
vm-image bare-bones.tmpl’ runs in ~2m42s on my SSD-based laptop.  The
key commits here are fce225471128c4a5246342b3aa1b7e53a8066211 and
bb3b6ccb05550fbfbeb459c68819a752327d6e1e.

Regarding deduplication (commit
b5460d95e970608bee7a794590be1b051b57d3a3), I found that it doesn’t
change the image size of bare-bones.tmpl (1.2G), but enabling it makes
things slower, ~6m.

Lemme know how it goes for you!

Thanks,
Ludo’.

[Message part 3 (message/rfc822, inline)]
From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guix <at> gnu.org
Cc: Leo Famulari <leo <at> famulari.name>
Subject: ‘guix system vm-image’
 spends a very long time “registering closures”
Date: Fri, 31 Aug 2018 12:07:19 +0200
Hi,

A couple of days ago, Leo reported that ‘guix system vm-image’ spends a
very long time in the “registering closures” phase:

--8<---------------cut here---------------start------------->8---
<lfam> I wonder about the slowness of 'registering closures' with `guix system
       vm-image` and similiar commands. I don't remember this taking so long
       in the past  [22:52]

[...]

<lfam> Created a bare-bones VM takes ~90 minutes for me recently
<lfam> s/Created/Creating
<civodul> with vm-image?
<lfam> Yes

[...]

<lfam> With #:reset-timestamps #f, I cancelled the task after 10 minutes of
       'registering closures'  [23:33]

[...]

<civodul> lfam: i added some pk's and it seems that it's deduplucation that's
	  killing us  [00:41]
<civodul> because it involves retraversing each store item and reading each
	  file  [00:42]
<lfam> It does it for each file?
<lfam> Or, you could just point me to the relevant code so I can learn it :)
<civodul> yeah, it has to read them to be able to determine if there are
	  duplicates
<civodul> (guix store database) calls the deduplication code  [00:43]
<civodul> which is in (guix store deduplication)
<civodul> (reepca's code from last year's GSoC)
<civodul> maybe c45477d2a1a651485feede20fe0f3d15aec48b39 or something close
	  inadvertently turned on deduplication  [00:44]
<civodul> so in (gnu system vm), we could pass #:deduplicate? #f to
	  'root-partition-initializer'
--8<---------------cut here---------------end--------------->8---

Ludo’.



This bug report was last modified 6 years and 326 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.