Date: Fri, 23 Dec 2022 15:47:33 -0800 From: Mark Millard <marklmi@yahoo.com> To: 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: <DCF28C01-475C-42B1-A690-90D67A5CCBC6@yahoo.com> References: <DCF28C01-475C-42B1-A690-90D67A5CCBC6.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 : > >=20 > >> 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?] > >=20 > >=20 > > = https://lists.freebsd.org/archives/freebsd-ports/2022-December/003153.html= > >=20 > > indicates a problem with tmpfs use such that using USE_TMPFS=3Dno > > 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.) >=20 > I'll try disabling tmpfs on synth. >=20 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=3Dall= 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.a= md64/sys/GENERIC-NODBG amd64 amd64 1400073 1400073 and it got the problem. (I normally use USE_TMPFS=3Ddata , 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DCF28C01-475C-42B1-A690-90D67A5CCBC6>