Date: Sun, 16 Apr 2023 10:47:39 -0700 From: Mark Millard <marklmi@yahoo.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: FreeBSD User <freebsd@walstatt-de.de>, Cy Schubert <Cy.Schubert@cschubert.com>, Charlie Li <vishwin@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, dev-commits-src-main@freebsd.org, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 Message-ID: <00F473F6-ECE9-41F9-BA87-A021572E9776@yahoo.com> In-Reply-To: <CDF64147-65D7-4DA0-860B-8C0305793F05@yahoo.com> References: <20230413071032.18BFF31F@slippy.cwsent.com> <D0D9BD06-C321-454C-A038-C55C63E0DD6B@dawidek.net> <20230413063321.60344b1f@cschubert.com> <CAGudoHG3rCx93gyJTmzTBnSe4fQ9=m4mBESWbKVWtAGRxen_4w@mail.gmail.com> <20230413135635.6B62F354@slippy.cwsent.com> <c41f9ed6-e557-9255-5a46-1a22d4b32d66@dawidek.net> <319a267e-3f76-3647-954a-02178c260cea@dawidek.net> <b60807e9-f393-6e6d-3336-042652ddd03c@freebsd.org> <441db213-2abb-b37e-e5b3-481ed3e00f96@dawidek.net> <5ce72375-90db-6d30-9f3b-a741c320b1bf@freebsd.org> <99382FF7-765C-455F-A082-C47DB4D5E2C1@yahoo.com> <32cad878-726c-4562-0971-20d5049c28ad@freebsd.org> <ABC9F3DB-289E-455E-AF43-B3C13525CB2C@yahoo.com> <20230415115452.08911bb7@thor.intern.walstatt.dynvpn.de> <20230415143625.99388387@slippy.cwsent.com> <20230415175218.777d0a97@thor.intern.walstatt.dynvpn.de> <CAGudoHHnimmsgXTBjrcY=FiYnQCoh7m8zhBM4BPYHoFy%2BihUxQ@mail.gmail.com> <3BB7D5DD-99A6-4D27-BBB6-4CD3294EEDF9@yahoo.com> <96A74C34-22FE-4F7D-B032-16313B6E1612@yahoo.com> <CDF64147-65D7-4DA0-860B-8C0305793F05@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 16, 2023, at 10:40, Mark Millard <marklmi@yahoo.com> wrote: > On Apr 16, 2023, at 01:34, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On Apr 15, 2023, at 19:13, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> A general question is all for this message. >>>=20 >>> So far no commit to FeeeBSD's main seems to be >>> analogous to the content of: >>>=20 >>> https://github.com/openzfs/zfs/pull/14739/files >>>=20 >>> After my existing poudriere bulk test finishes, >>> should I avoid having the content of that change >>> in place for future testing? Vs.: Should I keep >>> using the content of that change? >>>=20 >>> (The question is prompted by the 2 recent commits >>> that I will update my test environment to be using, >>> in part by fetching and updating to a new head, >>> avoiding the "no dnode_next_offset change" status >>> that my existing test has.) >>>=20 >>=20 >> Not knowing, I updated to: >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #92 = main-n262185-b1a00c2b1368-dirty: Sun Apr 16 00:10:51 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 >>=20 >> with the following still in place: >>=20 >> # git -C /usr/main-src/ diff sys/contrib/openzfs/ >> diff --git a/sys/contrib/openzfs/module/zfs/dmu.c = b/sys/contrib/openzfs/module/zfs/dmu.c >> index ce985d833f58..cda1472a77aa 100644 >> --- a/sys/contrib/openzfs/module/zfs/dmu.c >> +++ b/sys/contrib/openzfs/module/zfs/dmu.c >> @@ -2312,8 +2312,10 @@ dmu_brt_clone(objset_t *os, uint64_t object, = uint64_t offset, uint64_t length, >> dl->dr_overridden_by.blk_phys_birth =3D 0; >> } else { >> dl->dr_overridden_by.blk_birth =3D dr->dr_txg; >> - dl->dr_overridden_by.blk_phys_birth =3D >> - BP_PHYSICAL_BIRTH(bp); >> + if (!BP_IS_EMBEDDED(bp)) { >> + dl->dr_overridden_by.blk_phys_birth =3D= >> + BP_PHYSICAL_BIRTH(bp); >> + } >> } >> mutex_exit(&db->db_mtx); >>=20 >>=20 >>=20 >> and booted the update. I've done a: >>=20 >> # poudriere pkgclean -jmain-CA72-bulk_a -A >>=20 >> and started another package build run based >> on that combination: >>=20 >> # poudriere bulk -jmain-CA72-bulk_a -w -f ~/origins/CA72-origins.txt >> . . . >> [main-CA72-bulk_a-default] [2023-04-16_00h38m01s] [balancing_pool:] = Queued: 476 Built: 0 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 = Tobuild: 476 Time: 00:00:24 >> [00:00:37] Recording filesystem state for prepkg... done >> [00:00:37] Building 476 packages using up to 16 builders >> [00:00:37] Hit CTRL+t at any time to see build progress and stats >> [00:00:37] [01] [00:00:00] Builder starting >> [00:00:40] [01] [00:00:03] Builder started >> [00:00:40] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.19.1_1 >> . . . >>=20 >> If there are no failures, it will be about 9 hrs before I know that. >> Given that I'll be trying to sleep soon, it may be about that long >> either way. >=20 > [Reminder: All my testing has been of a "block_cloning was > never enabled" context. This one has the dnode_next_offset > change involved, unlike the prior one.] >=20 > There was one failed fetch but no other failures: >=20 > [01:25:02] [04] [00:01:07] Finished ports-mgmt/fallout | = fallout-1.0.4_8: Failed: fetch > . . . > [09:13:58] Failed ports: ports-mgmt/fallout:fetch > [main-CA72-bulk_a-default] [2023-04-16_00h38m01s] [committing:] = Queued: 476 Built: 475 Failed: 1 Skipped: 0 Ignored: 0 Fetched: 0 = Tobuild: 0 Time: 09:13:45 >=20 > Running the bulk again: >=20 > . . . > [00:00:22] Building 1 packages using up to 1 builders > [00:00:22] Hit CTRL+t at any time to see build progress and stats > [00:00:22] [01] [00:00:00] Builder starting > [00:00:24] [01] [00:00:02] Builder started > [00:00:24] [01] [00:00:00] Building ports-mgmt/fallout | = fallout-1.0.4_8 > [00:01:04] [01] [00:00:40] Finished ports-mgmt/fallout | = fallout-1.0.4_8: Success > . . . >=20 > I do not expect the fetch issue is evidence of a problem. By omission, I was too vague about that. The log's error message was: go: golang.org/x/text@v0.3.7: read = "https:/proxy.golang.org/@v/v0.3.7.zip": read tcp = 192.168.1.110:47155->142.251.215.241:443: read: connection reset by peer > I'm counting this as: No evidence of corruption problems. >=20 =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?00F473F6-ECE9-41F9-BA87-A021572E9776>