From nobody Sat Dec 24 00:25:32 2022 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nf4b21xq3z1GyZw; Sat, 24 Dec 2022 00:25:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nf4b14X14z4QPS; Sat, 24 Dec 2022 00:25:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 2BO0PWjZ032512 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 24 Dec 2022 02:25:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 2BO0PWjZ032512 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 2BO0PWZF032511; Sat, 24 Dec 2022 02:25:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 Dec 2022 02:25:32 +0200 From: Konstantin Belousov To: Mark Millard Cc: Jonathan Chen , FreeBSD-STABLE Mailing List , freebsd-current Subject: Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem report on freebsd-ports?) Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home X-Rspamd-Queue-Id: 4Nf4b14X14z4QPS X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 23, 2022 at 03:47:33PM -0800, Mark Millard wrote: > Jonathan Chen wrote on > Date: Fri, 23 Dec 2022 18:40:27 UTC : > > > On 24/12/22 07:14, Mark Millard wrote: > > > Jonathan Chen wrote on > > > Date: Thu, 22 Dec 2022 19:21:37 UTC : > > > > > >> I recently updated my package builder machine to the > > >> stable/13-n253297-fc15d5bf1109of (22-Dec-2022); and appear to be having > > >> some unusual issues when building with a high number of jobs. My package > > >> builder uses synth (which uses nullfs on ZFS), and I have had failures > > >> with missing files, as well as what appears to be sequencing issues with > > >> Makefiles. If I re-run the build, these errors usually do not reoccur. > > >> > > >> I'm puzzled as to what is happening. Is this just happening to me? It > > >> appears that the ZFS code has been updated recently, and I'm wondering > > >> whether a regression has crept in. [Or it could just be my hardware?] > > > > > > > > > https://lists.freebsd.org/archives/freebsd-ports/2022-December/003153.html > > > > > > indicates a problem with tmpfs use such that using USE_TMPFS=no > > > avoids a problem for poudriere bulk builds on 13.1 amd64. > > > (Unclear if the note is for stable/13 vs. releng/13.1 vs. both.) > > > > I'll try disabling tmpfs on synth. > > > > > FYI . . . > > The following is about the tmpfs issue referenced in > freebsd-ports/2022-December/003153.html . > > Here is what is going on (manually entered commands, not a script). First under a tmpfs: > > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ufs/rootfs 221683 97879 106068 48% / > devfs 0 0 0 100% /dev > /dev/msdosfs/MSDOSBOOT 49 31 18 62% /boot/msdos > tmpfs 7716 0 7716 0% /tmp > # cd /tmp > # : > mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 08:56:53 2022 mmjnk.test > # : > mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 08:56:53 2022 mmjnk.test > > (no time change). The makefile involved is using ": > NAME" notation > to try to update timestamps on deliberately empty files. > > Vs. under (for example) UFS: > > # cd ~/ > # : > mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:00:45 2022 mmjnk.test > # : > mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:00:54 2022 mmjnk.test > > (time changed). > > Back in tmpfs land . . . > > Part of this is that the file is already of size zero and continues > to be so. By contrast, starting with a file with 15 bytes in it: > > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 15 Mar 9 09:07:38 2022 mmjnk.test > # : > mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:07:49 2022 mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:07:49 2022 mmjnk.test > > The lack of a timestamp change when the file already has size zero > looks like an example of a bug to me. > > truncate for tmpfs files behaves similarly (showing just the > lack of timestamp change context): > > # truncate -s 0 mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test > # truncate -s 0 mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test > > (UFS got a timestamp update from such a sequence.) > > > I'll note that touch does not get this tmpfs behavior: > > # touch mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:11:26 2022 mmjnk.test > # touch mmjnk.test > # ls -Tld mmjnk.test > -rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test > > (But it would not force size zero on its down.) > > I did these tests on: > > # uname -apKU > FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 stable/13-n253133-b51ee7ac252c: Wed Nov 23 03:36:16 UTC 2022 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1301509 1301509 > > However, I previously did a devel/nasm bulk test with with USE_TMPFS=all on: > > # uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #55 main-n259064-f83db6441a2f-dirty: Sun Nov 6 16:31:55 PST 2022 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400073 1400073 > > and it got the problem. (I normally use USE_TMPFS=data , which does not > get the problem because the files in question end up not on a tmpfs.) > > So: not specific to amd64 , not specific to stable/13 , existed in early > November in main. This may have been around for some time for tmpfs. Should be fixed by https://reviews.freebsd.org/D37866