From owner-freebsd-current@freebsd.org Sun Nov 22 17:42:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BF7E46EF56 for ; Sun, 22 Nov 2020 17:42:27 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CfHfp6Rl3z3lmK; Sun, 22 Nov 2020 17:42:26 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-ej1-f49.google.com with SMTP id s25so20085677ejy.6; Sun, 22 Nov 2020 09:42:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=A1HIgrjD+Fqa5VOpOff3G0t4lfxvTRbKshqIsuUwdJc=; b=Ahd9x7yFWiEzXa4UnsQ22PZfYRC3vc+wuJ8+lmulbwnXzn8z8lpn7w+hj8joUZx1o4 9/53uRTqTMG+Sj4+7FTnR26WsUaC1ccxUkp4cV2n/2HISVnX1wBRhqpaGdzhJO8ecE4w Gg18Qp0AFVxLx4Be1NtElhRrxRL8t6xt2m94BER0paSUvbUO//R45quOT6bmdqx/9scH 3l/sjMlZ5LKJcI40bifH+ZL8ZIqRYAFp/mYZXmonJCihBUMoWRf/A/PNyIXGwkxnbxrc 6vMCUfypRhebvApLy5bQB9PfbJQrHqpuVF7AaqaRhmuxYPAUdJXW6Xne+xpMPQk75j6p CXYA== X-Gm-Message-State: AOAM5328howLXppPFeAQLTSv/fuGQVZQa5GnA+jtQXhoYk/6Zr7WY+n3 h7YJO/nNOG9oFEJ57bChVjkGttopydDahRSa X-Google-Smtp-Source: ABdhPJxRNBlSP93JVc6LdA5/J7BK8E/jkk7u6GV+GRNIjLJViSxrR9xfe6xD9n3TWi7l9dG+zHoZ1Q== X-Received: by 2002:a17:906:bcf9:: with SMTP id op25mr39735969ejb.223.1606066945273; Sun, 22 Nov 2020 09:42:25 -0800 (PST) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com. [209.85.128.44]) by smtp.gmail.com with ESMTPSA id b21sm3770186ejg.93.2020.11.22.09.42.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Nov 2020 09:42:24 -0800 (PST) Received: by mail-wm1-f44.google.com with SMTP id a65so15161337wme.1; Sun, 22 Nov 2020 09:42:24 -0800 (PST) X-Received: by 2002:a1c:f219:: with SMTP id s25mr3200782wmc.67.1606066944546; Sun, 22 Nov 2020 09:42:24 -0800 (PST) MIME-Version: 1.0 References: <746a3af4-3daf-9029-bf48-23efa3f5da8e@gmail.com> <37d2a873-8cb9-b858-fa06-4bbfcf006835@gmail.com> <1e9e8649-0fe7-4b83-078d-f67908e2f430@gmail.com> <40C5DB30-4B7C-4A51-8069-B4E67298C558@FreeBSD.org> In-Reply-To: From: Alexander Richardson Date: Sun, 22 Nov 2020 17:42:12 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71 To: Kyle Evans Cc: Dimitry Andric , Graham Perrin , FreeBSD-CURRENT , Ryan Moeller , Matthew Macy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4CfHfp6Rl3z3lmK X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 17:42:27 -0000 On Sun, 22 Nov 2020 at 16:06, Kyle Evans wrote: > > On Sun, Nov 22, 2020 at 6:00 AM Dimitry Andric wrote: > > > > On 22 Nov 2020, at 08:06, Graham Perrin wrote: > > > > > > On 20/11/2020 09:57, Graham Perrin wrote: > > >> On 16/11/2020 09:27, Graham Perrin wrote: > > >>> Attempting to build r367615 on Friday 13th: > > >>> > > >>> =E2=80=A6 > > >>> > > >>> =3D=3D=3D> lib/libprocstat/zfs (install) > > >>> install -U -C -o root -g wheel -m 444 /usr/src/lib/libprocstat/lib= procstat.h /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ > > >>> =3D=3D=3D> lib/libc (obj,all,install) > > >>> install -U -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/am= d64.amd64/tmp/usr/lib/ > > >>> install -U -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr= /src/amd64.amd64/tmp/lib/ > > >>> install -U -o root -g wheel -m 444 libc.so.7.debug /usr/obj/usr= /src/amd64.amd64/tmp/usr/lib/debug/lib/ > > >>> install: short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/de= bug/lib/libc.so.7.debug: 393216 bytes written, 7462472 bytes asked to write > > >>> *** [_libinstall] Error code 71 > > >>> > > >>> make[4]: stopped in /usr/src/lib/libc > > >>> 1 error > > >>> > > >>> make[4]: stopped in /usr/src/lib/libc > > >>> root@mowa219-gjp4-8570p:/usr/src # > > >> > > >> The same problem =E2=80=93 short write to /usr/obj/usr/src/amd64.amd= 64/tmp/usr/lib/debug/lib/libc.so.7.debug =E2=80=93 when attempting buildwor= ld of r367847. > > >> > > >> If it's relevant: I'm using r367081 for these attempts. > > > > > > The same problem when attempting buildworld of r367923. Prior to this= I performed a fresh checkout of /usr/src > > > > > > What might cause these failures? > > > > > > If it's relevant: I have compression set to gzip-9 for the ZFS datase= t that mounts at /usr > > > > I'd guess it's an unintended side-effect of > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D366697 > > ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on > > size"). > > > > Almost certainly -- before, we would never attempt to mmap() on ZFS. > > Tossing arichardson@ into CC as the committer > Tossing mmacy@ and freqlabs@ into CC as ZFS folks > > Looking through sys/contrib/openzfs, there's special handling for mmap > on linux because it bypasses the page cache and relies on caching in > ARC. AFAICT the FreeBSD side seems to handle write() to mmap'd > regions, but doesn't do anything with VOP_MMAPPED which might be > needed to sync the file when it's mmap'd for reading like this. My > understanding of how this is supposed to actually work on FreeBSD is > limited, though, so I defer... > I'm quite surprised by this, I simply re-used the logic that bin/cp also ha= s. However, it's possible that this is no longer used in cp due to copy_file_r= ange? To be honest I'm not sure whether mmap() even improves performance compared to read/write since the all the MMU setup might be quite expensive and the data might not even be available so we end up copying anyway. Maybe we should change install to use read/write unconditionally? It might also make sense to factor out the copy_file_range+read/write fallback logic in bin/cp to a library that can be used in usr.bin/install. Alex