Date: Sat, 24 Dec 2022 02:25:32 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: Jonathan Chen <jonc@chen.org.nz>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem report on freebsd-ports?) Message-ID: <Y6ZG/AqyLRtyRh9K@kib.kiev.ua> In-Reply-To: <DCF28C01-475C-42B1-A690-90D67A5CCBC6@yahoo.com> References: <DCF28C01-475C-42B1-A690-90D67A5CCBC6.ref@yahoo.com> <DCF28C01-475C-42B1-A690-90D67A5CCBC6@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 23, 2022 at 03:47:33PM -0800, Mark Millard wrote: > Jonathan Chen <jonc_at_chen.org.nz> wrote on > Date: Fri, 23 Dec 2022 18:40:27 UTC : > > > On 24/12/22 07:14, Mark Millard wrote: > > > Jonathan Chen <jonc_at_chen.org.nz> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Y6ZG/AqyLRtyRh9K>