NetBSD Problem Report #47562

From  Wed Feb 13 10:58:39 2013
Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id 45DEF63E5A2
	for <>; Wed, 13 Feb 2013 10:58:39 +0000 (UTC)
Subject: very slow installworld
X-Send-Pr-Version: 3.95

>Number:         47562
>Category:       toolchain
>Synopsis:       very slow installworld
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lukem
>State:          analyzed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 13 11:00:01 +0000 2013
>Last-Modified:  Thu Jun 15 20:19:59 +0000 2023
>Originator:     Martin Husemann
>Release:        NetBSD 6.99.16
The NetBSD Foundation, Inc.
System: NetBSD 6.99.16 NetBSD 6.99.16 (MODULAR) #40: Tue Feb 5 20:22:09 CET 2013 sparc64
Architecture: sparc64
Machine: sparc64

Recent changes to mtree/sets installation caused a significant slowdown
of "make installworld", maybe due to a lot of hashes being calculated
and then ignored?

I often mount the source tree and a prebuild DESTDIR via nfs, then do
a "make installworld" on the NFS client machine.

It then does:

installsets ===> distrib/sets   (with: INSTALLDIR=/ INSTALLSETS=)
cd /usr/src/distrib/sets &&  DESTDIR=/mnt  MACHINE=sparc64  MACHINE_ARCH=sparc64  AWK=awk  CKSUM=cksum  DB=db  HOST_SH=/bin/sh  MAKE=make  MKTEMP=mktemp  MTREE=mtree  PAX=pax  COMPRESS_PROGRAM=gzip  PKG_CREATE=pkg_create  SED=sed  TSORT=tsort\ -q  /bin/sh ./maketars -d /mnt    -N /usr/src/etc  -L base,x -i / 
Copying set base
Copying set comp

The "long pause" was there before, but it got significantly longer recently
and on slower machines now can be in the hours magnitude.

I assume this time is spent calculating hash values for mtree output, which
is not realy used during this procedure. While uniformication of the process
is good, this might be a case for an exception.

make installworld on a m68k machine ;-)



From: "Luke Mewburn" <>
Subject: PR/47562 CVS commit: src
Date: Sat, 10 Jun 2023 16:08:41 +0000

 Module Name:	src
 Committed By:	lukem
 Date:		Sat Jun 10 16:08:41 UTC 2023

 Modified Files:
 	src/distrib/sets: Makefile maketars

 Log Message:
 sets: enhance MAKEVERBOSE support

 Add more messages for various sets operations.
 Add ${_MKMSG_CREATE} to

 Enhance maketars to be a bit more verbose even with -q,
 to make it more obvious why certain operations may be slow.
 May help debugging PR 47562.

 To generate a diff of this commit:
 cvs rdiff -u -r1.108 -r1.109 src/distrib/sets/Makefile
 cvs rdiff -u -r1.95 -r1.96 src/distrib/sets/maketars
 cvs rdiff -u -r1.1341 -r1.1342 src/share/mk/

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: toolchain-manager->lukem
Responsible-Changed-When: Sat, 10 Jun 2023 17:50:09 +0000

State-Changed-From-To: open->analyzed
State-Changed-When: Sat, 10 Jun 2023 17:50:09 +0000

I've looked into the history of the mtree/sets installation from before
2013-02-13 (per your "Recent changes" in the description).  I couldn't
see anything specifically obvious.

There were distrib/sets changes around 2013-02-06 by Christos
to use mtree to generate the set lists when the METALOG isn't
present (when MKUNPRIVED=no):
        revision 1.77
        date: 2013-02-06 12:01:12 +1100;  author: christos;  state: Exp;  lines: +8 -8;
        Create full sets using mtree from the flists (not just filenames).

which may be the cause of your "{*LONG PAUSE HERE*}", beacuse
the etc/mtree/sets.* files with their sha256 digests are being
calculated in "installsets" on the (slow) target machine.

In -current I've added more MAKEVERBOSE support into
distrib/sets/Makefile and distrib/sets/maketars;
if you run with MAKEVERBOSE=2 you may get more diagnostic
information to confirm which operations are causing the delays.

I'm not keen on adding an option in distrib/sets to disable
the generation of sha256 in MKUNPRIVED=no installsets, because
then the generation of /etc/mtree/* would then differ from
the MKUNPRIVED=yes equivalent

There's a couple of suggestions to avoid the slow issue:

Rather than explicitly strip out the sha256 in the MKUNPRIVED=no
installsets generation of /etc/mtree/* (which would then
differ from the MKUNPRIVED=yes equivalent), there's a couple
of suggestions to avoid the issue:

1. Cross-build sets on a faster machine and extract those.
   (I assume that's how you built the distribution on nfs?)

2. Cross-build with MKUNPRIVED=yes on a faster machine which
   generates the sha256 as each file is installed.
   Install on the destination with MKUNPRIVED=yes to enable
   using the existing METALOG.



NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: gnats-precook-prs,v 1.4 2018/12/21 14:20:20 maya Exp $
$NetBSD:,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.