NetBSD Problem Report #47562

From martin@duskware.de  Wed Feb 13 10:58:39 2013
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 45DEF63E5A2
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 13 Feb 2013 10:58:39 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
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
>Closed-Date:    
>Last-Modified:  Thu Jun 15 20:19:59 +0000 2023
>Originator:     Martin Husemann
>Release:        NetBSD 6.99.16
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD thirdstage.duskware.de 6.99.16 NetBSD 6.99.16 (MODULAR) #40: Tue Feb 5 20:22:09 CET 2013 martin@night-porter.duskware.de:/usr/src/sys/arch/sparc64/compile/MODULAR sparc64
Architecture: sparc64
Machine: sparc64
>Description:

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 / 
{*LONG PAUSE HERE*}
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.

>How-To-Repeat:
make installworld on a m68k machine ;-)

>Fix:
n/a

>Release-Note:

>Audit-Trail:
From: "Luke Mewburn" <lukem@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
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
 	src/share/mk: bsd.own.mk

 Log Message:
 sets: enhance MAKEVERBOSE support

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

 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/bsd.own.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-By: lukem@NetBSD.org
Responsible-Changed-When: Sat, 10 Jun 2023 17:50:09 +0000
Responsible-Changed-Why:


State-Changed-From-To: open->analyzed
State-Changed-By: lukem@NetBSD.org
State-Changed-When: Sat, 10 Jun 2023 17:50:09 +0000
State-Changed-Why:

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.

Thoughts?


>Unformatted:

Home	PR Database Search