From nobody Thu Apr 13 05:28:13 2023 X-Original-To: freebsd-current@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 4Pxp5Y4q9qz45TD0 for ; Thu, 13 Apr 2023 05:28:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4Pxp5W2gfgz4CTn for ; Thu, 13 Apr 2023 05:28:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PS3kauxm; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 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=1681363708; bh=L5q5sALpsYKoVMC4oyt29NhN4/yoqXPpBQbs936dfSU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=PS3kauxm6DIGSpv+1nAPbJvgDLEDgxxRyr/VOq231OFg5nyvM99UX54yEu+4sgcnDMV6PNDejV+nxpHqoqpbXFUoszLoNGh7OkCUIypmX5pu9wcUTNXoXYFrrQKuiT6MzAmkN+AOjgTk/7mWmcn+fZcM7Dw1rVv3ZVmT9V9QwZei5yIQ+5X+q9rGJBeRM+fN1XbW+Q9ntRBVUB1v+hES5sjXwiHZLPVV6CiWUc+LT5hf/0+GEb7zE/ZlshyqwRQmyNrHhKFdqLrnlZQNhtHK0F3ZAVm0wI26XDC0MpEyZwcBw5VDZbwL0vyafd/9/jCvoCqWF5G3ZCBLmV87Qqks4g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1681363708; bh=9O8rW1estJc8tDGxkleHYAB6B85vzwHUhYwQCGbopZc=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XwlfmPfn+k69bT0bqPGrXaT/CF8O6IYde2LI86+Y+6vyJUFnkLT5SzPdx6x4pMwcmlBOdDtveVGZBWjtDsTRz0T+VW22DKxkjD2rbJExCsEk0b8vDKxuu7i1BwRo5eqsjtgZChlF9T5KSxgk8GD8Yg6UnmZtwzFAPVfq0gyp8uzMXwZTxhvU5K8maFNZuiVpROHpMC2M8i1HsnZ4uJwS02aBG8K7jxK3xS66ccwTnGCoEVOkr6tzfg5ufUtUCtsJJ8oOqy9uy/gPNwZzH73p5sjfTd05SP/4sOIIf7U96SqCJqs8Ge7+LGAgZvm/8YF3pPaczC4DjGJ5l/KBpMnjyQ== X-YMail-OSG: 5xF05S8VM1mXlDt0Hhdjw3cXXeBxGBurn3vLXMQAvqBqn1tA6D6YiC3adyZdze4 us5XQpDTOHbBQPagLAZSQdMVN9jU0U3w1_y7DmP9jQLmG7w8s0gp_x8IO3dYLlhE7umUuxXxBY5W .qZBHxQ8z1WYx59_u3L0UqTiuNujZ9GLaKPS3TtsQEUdcqG7p5AKWVTtVmqtdwhCHBIcmqjKI3fh ZSAppnZ9oSzT2ggAAvX26_ONCVXzoWlf.g8h0ED66Dt.pHI.WTWWnVOolmu7C2i7Q.4Cn_qNJEDx 7OG.xNgnhOHqogDwFXWYBxaEKK9dDbrqKn2LaWADMUW_k_J_InlfkHczMVj99j428XjacWE2.IVf RTXzrEh_6f1Tj_nxoLUqNzcaBZJQoek4MkL9oJtIexBUu5mCo4yY4ZlY2pbEwgQwqW8t0NKRfqYf 7FPBkVTXAcGdxZhpYfo8IhT1gqUn4NvTqepr2ExGY1MpeqRH98O9.2WwidPBgw..hVD0MOMEjMi3 Ziqp3SdZLz9z5U9232vivoBZbfNH._GAxjX242TrhQ7OkFVUrUkYcTx_.7mAyEIzt3bm.M8e5lew TejtaTQl1itIqdBHhnTBw5K2Kq3X9pMvBEliT.blWmfXdJDmm50UQaw4Powbuo88chPQYxx4.4GZ JLV2OTG7JKjqbMcJO34Dbr4ynPm0NiW1moU9SS64XlKy3PUybLuCEeGWYPn6aE1wzUhaCcDp5rMa jPPoLBu2v5785TA1_ivqNo9c6JTZaCm3SUI8_Ml1evAoisHYWUNyPCY7RNBCMDJilMaw68RjTwHh Owetkp0syY7TgUOCxY4iNCiCKALyaB4Wyxxh8tRc7Ds0GdFajxPItQVXQbWtkgwDhbnouyL_vkpz VntGAj2KfoCcZGcyMo_Qhj6mbYYqjDKaYVHDhOrgbI2RbOqviTpwy0yCVoDuBjnUQcRfqh4ecukf qfuoyGIKJk70bRWZst7hWgOc3uXhEIGxuK2cunlVIPFqsKNFe8lqsFnAT7k9mQQx2wYAkAuNzEUv KZdoM6SPOIQt_3.b8BMC8YCRjXZSSKijtiACS1HomsK_X3f6mcUPBOY7n7J9x.FZjHyvIDPrA.8p Zyu9_RRJQNrwtKlOTP_h.p6iac3tuWSRgndW.JCohOD0m2O3ydgIMqaquQqesrbpaxg.2tQ8mEHR dHbFLwYldhtj6IVTdsESpzzY1KEqvfTnXqCMiR6xH4996p6hAB0jzmNXSS5qM1fv6ElLlH9pMoFH 9PMTu54j6CZNqoi.NgOkgHLMAXct01YxjAxiOYjvogwLuDjPy1KFTCda91AQFQqC.tM5ZVDqt529 DdhH_Kz5FlBSliO6vcQybcFydpnCMNGWK993yjFHglUDysaHcgijZIQ7wgKI_HyCl48Sbc53E9hm VebnVbtGr1LfxL9ms2FK9ooOUTXbpYKyaTyRNvQCJRzztqxuOnU2bSPI4TF86bXs01N18X5JgkdK NqBRyrkxFPY_1Mk.10rsOHsvyzokvh2xc9sICGgkksomV85OmrYyiZRkfm99d5lCZd5hwKqiH8sp 1awiKLIG7RpkwvXEqsWflmvkXAvaVa8DPeankxP6qgVnbhJ4SIxJ._dFJYa9LuN_WAG622IvCgWP 6JCsFxDbJC9K4vFqGVm2zVblHAkCC9HLwrrRyPvIhSXZ.dOvf_in2f0bRuh1DN9B.seVLj7f0c8u MA1gVZiIEICxG6Kb.friXcZ42BWw9ctStAbjk9wgQAtD..lOxVIVLmKei8waoebj__YjMOzl.ixL dQLEgpGuhXs3fc8f7plKXBKI4s0LsI63TvXr3rtc6NRe0a9LliwV7mr3zVWZc7iMwv2ci2l1pTV0 QQfsiZB1uPm3mrPLHHYUuFMjRgJl2t2So1OBvjKkxiiNMeGIOJnkz4PUctuyje30n7maq5VtGdyz e6EdWR_5f9GL4MN5rTfInWGjME1.0AVPgLTptQrPRZW2pbZDOOtrl8ND2lq0VvomLa.vejy15UPC FzVg_.KfzkGvay9XqYZVUcszNUCfn.t.9qmfOFWu_PYZ2kenY1s.zdfQQcOk93PIQO9CKU._He5B E7LLJr7vQ.JuEP9MxCxmedWLSRnwwi21YJ2SbbbWfWpPRtiB9gt251GJabAkvQqn.QWf66NCHJS3 Rj3s5OgyvP1vT_XF31xUj3ouMw.TeuEMi5AigtG8SlT3O5as3IAB3sErnjs.KoCbAa1ZSaHJR8xL a3ywt3qh6TwiI5s7JrRxoK425PJWSkuqARcArS3iFDiccjQH7NLOvO_d3RwG4ihxddw7vqAZ1XZM Ky.x_tg5v6QY- X-Sonic-MF: X-Sonic-ID: cad348fe-098d-41dd-8eef-80fc4c0e9dd6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Apr 2023 05:28:28 +0000 Received: by hermes--production-gq1-546798879c-dcj2l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 19058c53ce8266ee25011cb0f97af078; Thu, 13 Apr 2023 05:28:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-Id: Date: Wed, 12 Apr 2023 22:28:13 -0700 Cc: Cy Schubert To: Mateusz Guzik , vishwin@freebsd.org, dev-commits-src-main@freebsd.org, Current FreeBSD X-Mailer: Apple Mail (2.3731.400.51.1.1) References: X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from] X-Rspamd-Queue-Id: 4Pxp5W2gfgz4CTn X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N From: Charlie Li wrote on Date: Wed, 12 Apr 2023 20:11:16 UTC : > Charlie Li wrote: > > Mateusz Guzik wrote: > >> can you please test poudriere with > >> https://github.com/openzfs/zfs/pull/14739/files > >> > > After applying, on the md(4)-backed pool regardless of = block_cloning,=20 > > the cy@ `cp -R` test reports no differing (ie corrupted) files. Will=20= > > report back on poudriere results (no block_cloning). > >=20 > As for poudriere, build failures are still rolling in. These are (and=20= > have been) entirely random on every run. Some examples from this run: >=20 > lang/php81: > - post-install: @${INSTALL_DATA} ${WRKSRC}/php.ini-development=20 > ${WRKSRC}/php.ini-production ${WRKDIR}/php.conf = ${STAGEDIR}/${PREFIX}/etc > - consumers fail to build due to corrupted php.conf packaged >=20 > devel/ninja: > - phase: stage > - install -s -m 555=20 > /wrkdirs/usr/ports/devel/ninja/work/ninja-1.11.1/ninja=20 > /wrkdirs/usr/ports/devel/ninja/work/stage/usr/local/bin > - consumers fail to build due to corrupted bin/ninja packaged >=20 > devel/netsurf-buildsystem: > - phase: stage > - mkdir -p=20 > = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= tsurf-buildsystem/makefiles=20 > = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= tsurf-buildsystem/testtools > for M in Makefile.top Makefile.tools Makefile.subdir = Makefile.pkgconfig=20 > Makefile.clang Makefile.gcc Makefile.norcroft Makefile.open64; do \ > cp makefiles/$M=20 > = /wrkdirs/usr/ports/devel/netsurf-buildsystem/work/stage/usr/local/share/ne= tsurf-buildsystem/makefiles/;=20 > \ > done > - graphics/libnsgif fails to build due to NUL characters in=20 > Makefile.{clang,subdir}, causing nothing to link Summary: I have problems building ports into packages via poudriere-devel use despite being fully updated/patched (as of when I started the experiment), never having enabled block_cloning ( still using openzfs-2.1-freebsd ). In other words, I can confirm other reports that have been made. The details follow. [Written as I was working on setting up for the experiments and then executing those experiments, adjusting as I went along.] I've run my own tests in a context that has never had the zpool upgrade and that jump from before the openzfs import to after the existing commits for trying to fix openzfs on FreeBSD. I report on the sequence of activities getting to the point of testing as well. By personal policy I keep my (non-temporary) pool's compatible with what the most recent ??.?-RELEASE supports, using openzfs-2.1-freebsd for now. The pools involved below have never had a zpool upgrade from where they started. (I've no pools that have ever had a zpool upgrade.) (Temporary pools are rare for me, such as this investigation. But I'm not testing block_cloning or anything new this time.) I'll note that I use zfs for bectl, not for redundancy. So my evidence is more limited in that respect. The activities were done on a HoneyComb (16 Cortex-A72 cores). The system has and supports ECC RAM, 64 GiBytes of RAM are present. I started by duplicating my normal zfs environment to an external USB3 NVMe drive and adjusting the host name and such to produce the below. (Non-debug, although I do not strip symbols.) : # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 = main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 I then did: git fetch, stash push ., merge --ff-only, stash apply . : my normal procedure. I then also applied the patch from: https://github.com/openzfs/zfs/pull/14739/files Then I did: buildworld buildkernel, install them, and rebooted. The result was: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #91 = main-n262122-2ef2c26f3f13-dirty: Wed Apr 12 19:23:35 PDT 2023 = root@CA72_4c8G_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400086 1400086 The later poudriere-devel based build of packages from ports is based on: # ~/fbsd-based-on-what-commit.sh -C /usr/ports 4e94ac9eb97f (HEAD -> main, freebsd/main, freebsd/HEAD) = devel/freebsd-gcc12: Bump to 12.2.0. Author: John Baldwin Commit: John Baldwin CommitDate: 2023-03-25 00:06:40 +0000 branch: main merge-base: 4e94ac9eb97fab16510b74ebcaa9316613182a72 merge-base: CommitDate: 2023-03-25 00:06:40 +0000 n613214 (--first-parent --count for merge-base) poudriere attempted to build 476 packages, starting with pkg (in order to build the 56 that I explicitly indicate that I want). It is my normal set of ports. The form of building is biased to allowing a high load average compared to the number of hardware threads (same as cores here): each builder is allowed to use the full count of hardware threads. The build used USE_TMPFS=3D"data" instead of the USE_TMPFS=3Dall I normally use on the build machine involved. And it produced some random errors during the attempted builds. A type of example that is easy to interpret without further exploration is: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse = error at "'\x00\x00\x00\x00\x00\x00\x00\x00'": Expected W:(0-9A-Za-z) A fair number of errors are of the form: the build installing a previously built package for use in the builder but later the builder can not find some file from the package's installation. Another error reported was: ld: error: /usr/local/lib/libblkid.a: unknown file type For reference: [main-CA72-bulk_a-default] [2023-04-12_20h45m32s] [committing:] Queued: = 476 Built: 252 Failed: 11 Skipped: 213 Ignored: 0 Fetched: 0 = Tobuild: 0 Time: 00:37:52 I started another build that tried to build 224 packeges: the 11 failed and 213 skipped. Just 1 package built that failed before: [00:04:58] [09] [00:04:15] Finished databases/sqlite3@default | = sqlite3-3.41.0_1,1: Success It seems to be the only one where the original failure was not an example of complaining about the missing/corrupted content of a package install used for building. So it is an example of randomly varying behavior. That, in turn, allowed: [00:04:58] [01] [00:00:00] Building security/nss | nss-3.89 to build but everything else failed or was skipped. The sqlite3 vs. other failure difference suggests that writes have random problems but later reads reliably see the problem that resulted (before the content is deleted). After the above: # zpool status pool: zroot state: ONLINE config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p8 ONLINE 0 0 0 errors: No known data errors # zpool scrub zroot # zpool status pool: zroot state: ONLINE scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 = 22:15:39 2023 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 da0p8 ONLINE 0 0 0 errors: No known data errors =3D=3D=3D Mark Millard marklmi at yahoo.com