From nobody Fri Dec 23 23:47:33 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 4Nf3lH1gqTz1Lq1D for ; Fri, 23 Dec 2022 23:47:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nf3lG0RdPz4HvM for ; Fri, 23 Dec 2022 23:47:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ilcJV+Xn; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671839269; bh=S++yCKXxnvgQNJSpCsWxJU8y5zPrprseuvNThCXowhk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ilcJV+XnacZMyRPk0nD8wXi60AGk1G3i+nT4GSG7ukh3NmqkD0L1y0iUkBis+1+uzq1sCpyQ2O8nDfat5cgApfMsZ7Arm40i9g1ay01kpGVT49A7kjMQnfMovRLot8kvs1lNcFLBvoqI0tmvz9SdFrZHLBlxkuJENfzMO6vArQG6AtLFFALNZ1kNm0yBnA/TszutE/wCvz/Y6jRUvVkKWma7uIDrHruhv2vGk9AT/NHsAZnxVEpSyoCS4AuQg2yE+kuxJn2nqUAwoc00NrbR7UlRtxE+gGDzg/sd6fniY6ct34FJpRBnnc34+2cXtqcYs9UQ1VvG16E4OvJZ/X8pMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671839269; bh=mYFHuzCCKz4rwQszGrCTP7WU5KDmpQDPCXDz9IfXhkR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=AjnU604yVQO5cnYutfyp+FZWYAr4+1noUVuIxZDL6CUuERWwQ8TtkmEwrxSbVedk23zQchQXsC/CZJXoPb81wr1JGixQMQmxcvilIPsEL5LV5VMq5Cq3TlpaY8TJjyrVSiwgcarJ3DIXjdcYw3CLOpQbzahdHun6wcSpcI5ay5ERkaeuISQozqKxFbtBKdkvdv6FYumB6Yt5ANnJuW17+Bk2h0bOi+zm201+z+wyswwt7dR4PX+airGZx+dhM+aJH+eF6ZAu0zDfhLqGoc4VY0ao+/UaaOoeDqyEX3uTJQnsH1vdNIeF6Teyf3l3CIrelFoWhNglpmMY4NLzPmGa5w== X-YMail-OSG: 2icHlMoVM1lNUDgDCoKZa_582SEGKytyI81ictbtlBIROc1ijl.oi.e.RKWz.kr r1gVq.GGROzqhPeD.g6cFTKiEqcRoe6lV3PuKH73YlDZ4DniulrQRwSQ.4CiQdaaq4Rr1IJylV7m eQqM0y7SS6pO5WFPaDtj66X58Caw1qVOYz.wy_6dK1P.4lSJ41edmA0hTzdPcRdaL4bROR2nVdMA pdV9lWq.gXzaJClUcAkhGgdtYq7Z11m2h7jiqriOKgpxRyirnw8UdnImh48YXWPLsenjjeDQ0Ivm 1WGqoAMsHyukVjGyHHySpHr4tiJQOis8g1tLUwhPrgf_Uc61WDou7epktT507O7RafImacLa6xov t_AaLFgfaEe4Q4yohrX48zknkrEMG3suSd10q2u9q86g.PCFxj9dVFbBUJtK4vb6hp8ER5cb7ISa vLb1.6oR14xXupWSMSi82qN.IVfxZa7KV7pe2GrxTNQl6MqCiC8uGkdtsqFsueSNISFvwtCqpJwM 6tlqHu1xd4lVtSm4tmFxSjYr5gnwuiFTNFqJLOlsSplMPChu.iIDxDFUraJIJFdnoaupmmCkPXFz 8XuVr_TQhrs4hDjrLIanY3OsZ2965zIfQXzoGGkB.3WptefKpx0s3JS.DeNkyxPGgtIb7.HsUcFr utsN5M5SAvmlQk5HNBGfOOeGLnQYAzF4C0s86fJwEDbpNcGkrv3u4kVHm8Czru.UusDJPwi8LOkD MdDXzC9wAOEUV1LGC1G2y4gLaXIUoSTZmjBXOk4W4Abpz4XkCaDmld88KzlCfIlgZ2x07U_0SZzH 113UY_yc1rtkRh6.J2PDtNYv8meDNcuT9BWu0jjGIlWgFOBb4RDump9IRFi7hJGMVzku_8GSBkt1 _wSeS1xK6CqX0Xw.HuDa64.24mLltNknQjp8cL5vbwv8OAfmNYZstDrf1WG_bPFUzDJt.HsoJ2TW IVQoVX.TRW7zEzhmjJ.zjTb__sRP.NnEYqdOkiogcr1daZ3GDVCxBfq0vWLma_6YngfQetRLbn8A j.2funHsEAqbxSztm1ApUoTfzx3P7HomoFUWhYo8pxe7i8hbWdly4pAWlozM.TiZjFoUau9fwnAj U5ODrNtGi1rn2CdOUSuz.s6YWCNefdTOzU6kuXaA8OeNKugL_ZAG8B2VOe50gRfTFFZ77_n.QVXN Qm87JdeM6CuUbYJC0HjbnZvtDLoNWWsqYu3aSMSXiV8aU0ceSa2km9dYPmRDflORUTF6Lp5LE9_V knXsvNA.hrTe.EVUkglSHgm3IFXkp2_Al8eAzud2BrKuvlB2HOjdEBfSE63IueAVXNTN6JxFaFvl Xk4w14Pgv0fpBOZW5Mkqah1C4BVfV.h9LP7YVMxMsabtHpLTzTkKExKAjFzV_WLQBhVWM4au.3kS kN25IxAcAEiH17iWE99S4gP.kNwnmu6LdFKbDaZSwdNIeSNh.HgEtOuzS2_6dmh_o_YxUbu6kLUb prale4Gxt2XQhc9eES3ff26XDGzlu9sibHploIJb9FzWlHAHC7Sp3gdnDnC7AIPQHrggH1Drt.Jh r1Dj9o8jExvQafmKOsh3.B9KOdyWEFtdEA_oF5l0pdCW3LBiWvPGsg8eqxhfzCvuYZKvRZ2TQ5AM 9OZ_i2A4WUuPMR65.Gxnkf2nXS1PU_KvoqVabRPI9QXOJ8XdEDTUKrajzpStPEEJ6eYT51bYxcrJ 9sfuiTDIjZF6PX3fyabLfUKHJzH0OxG9seYd6CXRX.HOeFAaK5It7cD7OSJDKX.GCcr7xxv_vTT_ eWq0KqL1Aoq3leKZm7d0MoxQdEnNLyX3nHLmgTQ9CUdgmhbeABzXrzdR8opXEwz4LdNZdRYP7aqz Y4TFVhANXeUITD23I3IqrrLHfZTyETu.v7fZ_ToMY3uLAhkn_jqZUOzsHMzXypXiycjLfEoj.Bit Oc131pL0vZ8kq0AL1VLCrVgcmB8vKL6ksZ3C7WyTtG6UYjdJHyHLKw7101evFn6V1.YJAfbfEqH5 IBuK7o6dFqlziI9Ub_070Wre958H8apjbxNke8UL6IcLk4pnnOCYZ4WUbCrAfecK9fo.mxXFaSbP hTfg6fnMd3TaDefXUSnaiaE9BAr4RadhB4ZHC8D_J2YbA_XMM5OLua_PLv2Qsb5HaMyRqRWz_Ttk rfoHjlTfaMuOIEO6ncUwtUysEBjvhbBRsuJnI7G8S9LT8ZMveCFpMiWQN5xXDddY7LzfUAEsHN_n SmUsKULCAtrJxVPzlVtxuXSmlBCJPoQvAXfRRTDEHT_SW.HcUiM6bwsnjlnjxBoyUaSkNJoLr2Zb 4 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 23 Dec 2022 23:47:49 +0000 Received: by hermes--production-bf1-5458f64d4-x4bxm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 268af7ab50cb22483dd25d695b525e81; Fri, 23 Dec 2022 23:47:45 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem report on freebsd-ports?) Message-Id: Date: Fri, 23 Dec 2022 15:47:33 -0800 To: Jonathan Chen , FreeBSD-STABLE Mailing List , freebsd-current X-Mailer: Apple Mail (2.3731.300.101.1.3) References: X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.995]; NEURAL_HAM_SHORT(-0.90)[-0.902]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; SUBJECT_HAS_QUESTION(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4Nf3lG0RdPz4HvM X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N 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 : > >=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