Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mark Millard]

On Apr 15, 2023, at 17:27, Mark Millard  wrote:

> On Apr 15, 2023, at 15:49, Mark Millard  wrote:
> 
>> . . .
>>> 
>>> 
>>> (Mostly written as I progressed but some material later
>>> inserted into/around previously written material.)
>>> 
>>> Summary:
>>> 
>>> As stands, it looks like reverting the dnode_is_dirty
>>> code is what fixes the corruptions that my type of
>>> test context produced via poudriere bulk activity .
>>> 
>>> 
>>> The details that lead to that summary . . .
>>> 
>>> Using my my build environment for updating my temporary,
>>> experimental context, an environment running a world and
>>> and kernel that predate the import:
>>> 
>>> # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72
>>>  arm64 aarch64 1400082 1400082
>>> 
>>> (Note the "nondbg": I normally run non-debug main builds,
>>> but with symbols not stripped.)
>>> 
>>> The kernel and world for this are what is in old-main-CA72:
>>> 
>>> # bectl list
>>> BEActive Mountpoint Space Created
>>> main-CA72 R  -  3.98G 2023-04-12 20:29
>>> old-main-CA72 N  /  1.08M 2023-02-06 19:44
>>> 
>>> (Most everything else is outside the BE's and so is shared
>>> across the BE's.)
>>> 
>>> I updated to also have (whitespace details likely
>>> not preserved in this note):
>>> 
>>> # git -C /usr/main-src/ diff 
>>> /usr/main-src/sys/contrib/openzfs/module/zfs/dnode.c
>>> diff --git a/sys/contrib/openzfs/module/zfs/dnode.c 
>>> b/sys/contrib/openzfs/module/zfs/dnode.c
>>> index 367bfaa80726..49a7f59c0da4 100644
>>> --- a/sys/contrib/openzfs/module/zfs/dnode.c
>>> +++ b/sys/contrib/openzfs/module/zfs/dnode.c
>>> @@ -1772,17 +1772,7 @@ dnode_is_dirty(dnode_t *dn)
>>> {
>>>  mutex_enter(>dn_mtx);
>>>  for (int i = 0; i < TXG_SIZE; i++) {
>>> -   list_t *list = >dn_dirty_records[i];
>>> -   for (dbuf_dirty_record_t *dr = list_head(list);
>>> -   dr != NULL; dr = list_next(list, dr)) {
>>> -   if (dr->dr_dbuf == NULL ||
>>> -   (dr->dr_dbuf->db_blkid != DMU_BONUS_BLKID &&
>>> -   dr->dr_dbuf->db_blkid != DMU_SPILL_BLKID)) {
>>> -   mutex_exit(>dn_mtx);
>>> -   return (B_TRUE);
>>> -   }
>>> -   }
>>> -   if (dn->dn_free_ranges[i] != NULL) {
>>> +   if (multilist_link_active(>dn_dirty_link[i])) {
>>>  mutex_exit(>dn_mtx);
>>>  return (B_TRUE);
>>>  }
>>> 
>>> 
>>> 
>>> 
>>> I did my usual buildworld buildkernel sequence and then
>>> one of my normal install sequences into main-CA72 to
>>> update it to have the change, as well as the prior
>>> material involved in my first experiment that I'd
>>> reported on.
>>> 
>>> I cleared the content of the jail that I use for
>>> temporary experiments, such as the prior testing that
>>> got the 11 builder failures:
>>> 
>>> # poudriere pkgclean -jmain-CA72-bulk_a -A
>>> 
>>> I then rebooted using the updated main-CA72 BE.
>>> 
>>> Then I started the:
>>> 
>>> # poudriere bulk -jmain-CA72-bulk_a -w -f ~/origins/CA72-origins.txt
>>> . . .
>>> [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:38] [01] [00:00:00] Builder starting
>>> [00:00:40] [01] [00:00:02] Builder started
>>> [00:00:40] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.19.1_1
>>> 
>>> In the prior experiment it got:
>>> 
>>> 476 = 252 success + 11 failed + 213 skipped
>>> 
>>> and it reported the time for that as: 00:37:52.
>>> 
>>> A normal from-scratch build takes many hours (multiple
>>> compiler toolchains and such) so my first report after
>>> this point will be for one of:
>>> 
>>> A) It got to, say, 00:40:00 or beyond with, or without
>>> failures.
>>> vs.
>>> B) It got failures and stopped before that.
>>> 
>>> . . . TIME GOES BY . . .
>>> 
>>> At about 00:40:00 the status was:
>>> 
>>> [00:40:00] [06] [00:00:00] Building x11/libXv | libXv-1.0.12,1
>>> load: 30.73  cmd: sh 1508 [nanslp] 2400.88r 6.69u 11.90s 0% 3960k
>>> [main-CA72-bulk_a-default] [2023-04-15_14h47m19s] [parallel_build:] Queued: 
>>> 476 Built: 235 Failed: 0   Skipped: 0   Ignored: 0   Fetched: 0   Tobuild: 
>>> 241  Time: 00:40:01
>>> ID  TOTALORIGIN   PKGNAME   
>>> PHASE PHASETMPFS   CPU% MEM%
>>> [15] 00:07:44 devel/py-lxml@py39 | py39-lxml-4.9.2   
>>> stage 00:00:08 40.00 KiB 0%   0%
>>> [01] 00:00:34 x11/libXxf86vm | libXxf86vm-1.1.4_3
>>> build-depends 00:00:03 56.00 KiB   2.3%   0%
>>> [16] 00:01:59 x11-toolkits/libXt | libXt-1.2.1,1 
>>> configure 

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mark Millard]

A general question is all for this message.

So far no commit to FeeeBSD's main seems to be
analogous to the content of:

https://github.com/openzfs/zfs/pull/14739/files

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?

(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.)

===
Mark Millard
marklmi at yahoo.com

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mark Millard]

On Apr 15, 2023, at 15:49, Mark Millard  wrote:

> . . .
>> 
>> 
>> (Mostly written as I progressed but some material later
>> inserted into/around previously written material.)
>> 
>> Summary:
>> 
>> As stands, it looks like reverting the dnode_is_dirty
>> code is what fixes the corruptions that my type of
>> test context produced via poudriere bulk activity .
>> 
>> 
>> The details that lead to that summary . . .
>> 
>> Using my my build environment for updating my temporary,
>> experimental context, an environment running a world and
>> and kernel that predate the import:
>> 
>> # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72
>>  arm64 aarch64 1400082 1400082
>> 
>> (Note the "nondbg": I normally run non-debug main builds,
>> but with symbols not stripped.)
>> 
>> The kernel and world for this are what is in old-main-CA72:
>> 
>> # bectl list
>> BEActive Mountpoint Space Created
>> main-CA72 R  -  3.98G 2023-04-12 20:29
>> old-main-CA72 N  /  1.08M 2023-02-06 19:44
>> 
>> (Most everything else is outside the BE's and so is shared
>> across the BE's.)
>> 
>> I updated to also have (whitespace details likely
>> not preserved in this note):
>> 
>> # git -C /usr/main-src/ diff 
>> /usr/main-src/sys/contrib/openzfs/module/zfs/dnode.c
>> diff --git a/sys/contrib/openzfs/module/zfs/dnode.c 
>> b/sys/contrib/openzfs/module/zfs/dnode.c
>> index 367bfaa80726..49a7f59c0da4 100644
>> --- a/sys/contrib/openzfs/module/zfs/dnode.c
>> +++ b/sys/contrib/openzfs/module/zfs/dnode.c
>> @@ -1772,17 +1772,7 @@ dnode_is_dirty(dnode_t *dn)
>> {
>>   mutex_enter(>dn_mtx);
>>   for (int i = 0; i < TXG_SIZE; i++) {
>> -   list_t *list = >dn_dirty_records[i];
>> -   for (dbuf_dirty_record_t *dr = list_head(list);
>> -   dr != NULL; dr = list_next(list, dr)) {
>> -   if (dr->dr_dbuf == NULL ||
>> -   (dr->dr_dbuf->db_blkid != DMU_BONUS_BLKID &&
>> -   dr->dr_dbuf->db_blkid != DMU_SPILL_BLKID)) {
>> -   mutex_exit(>dn_mtx);
>> -   return (B_TRUE);
>> -   }
>> -   }
>> -   if (dn->dn_free_ranges[i] != NULL) {
>> +   if (multilist_link_active(>dn_dirty_link[i])) {
>>   mutex_exit(>dn_mtx);
>>   return (B_TRUE);
>>   }
>> 
>> 
>> 
>> 
>> I did my usual buildworld buildkernel sequence and then
>> one of my normal install sequences into main-CA72 to
>> update it to have the change, as well as the prior
>> material involved in my first experiment that I'd
>> reported on.
>> 
>> I cleared the content of the jail that I use for
>> temporary experiments, such as the prior testing that
>> got the 11 builder failures:
>> 
>> # poudriere pkgclean -jmain-CA72-bulk_a -A
>> 
>> I then rebooted using the updated main-CA72 BE.
>> 
>> Then I started the:
>> 
>> # poudriere bulk -jmain-CA72-bulk_a -w -f ~/origins/CA72-origins.txt
>> . . .
>> [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:38] [01] [00:00:00] Builder starting
>> [00:00:40] [01] [00:00:02] Builder started
>> [00:00:40] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.19.1_1
>> 
>> In the prior experiment it got:
>> 
>> 476 = 252 success + 11 failed + 213 skipped
>> 
>> and it reported the time for that as: 00:37:52.
>> 
>> A normal from-scratch build takes many hours (multiple
>> compiler toolchains and such) so my first report after
>> this point will be for one of:
>> 
>> A) It got to, say, 00:40:00 or beyond with, or without
>>  failures.
>> vs.
>> B) It got failures and stopped before that.
>> 
>> . . . TIME GOES BY . . .
>> 
>> At about 00:40:00 the status was:
>> 
>> [00:40:00] [06] [00:00:00] Building x11/libXv | libXv-1.0.12,1
>> load: 30.73  cmd: sh 1508 [nanslp] 2400.88r 6.69u 11.90s 0% 3960k
>> [main-CA72-bulk_a-default] [2023-04-15_14h47m19s] [parallel_build:] Queued: 
>> 476 Built: 235 Failed: 0   Skipped: 0   Ignored: 0   Fetched: 0   Tobuild: 
>> 241  Time: 00:40:01
>> ID  TOTALORIGIN   PKGNAME   
>> PHASE PHASETMPFS   CPU% MEM%
>> [15] 00:07:44 devel/py-lxml@py39 | py39-lxml-4.9.2   
>> stage 00:00:08 40.00 KiB 0%   0%
>> [01] 00:00:34 x11/libXxf86vm | libXxf86vm-1.1.4_3
>> build-depends 00:00:03 56.00 KiB   2.3%   0%
>> [16] 00:01:59 x11-toolkits/libXt | libXt-1.2.1,1 
>> configure 00:00:52 40.00 KiB   0.3%   0%
>> [02] 00:01:40 devel/dbus | dbus-1.14.6,1 
>> configure 00:00:05 36.00 KiB   0.5%   0%
>> [03] 00:02:20 

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mark Millard]

On Apr 15, 2023, at 15:33, Mark Millard  wrote:

> On Apr 15, 2023, at 13:30, Mateusz Guzik  wrote:
> 
>> On 4/15/23, FreeBSD User  wrote:
>>> Am Sat, 15 Apr 2023 07:36:25 -0700
>>> Cy Schubert  schrieb:
>>> 
 In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
 FreeBSD Us
 er writes:
> Am Thu, 13 Apr 2023 22:18:04 -0700
> Mark Millard  schrieb:
> 
>> On Apr 13, 2023, at 21:44, Charlie Li  wrote:
>> 
>>> Mark Millard wrote:
 FYI: in my original report for a context that has never had
 block_cloning enabled, I reported BOTH missing files and
 file content corruption in the poudriere-devel bulk build
 testing. This predates:
 https://people.freebsd.org/~pjd/patches/brt_revert.patch
 but had the changes from:
 https://github.com/openzfs/zfs/pull/14739/files
 The files were missing from packages installed to be used
 during a port's build. No other types of examples of missing
 files happened. (But only 11 ports failed.)
>>> I also don't have block_cloning enabled. "Missing files" prior to
>>> brt_rev
> ert may actually
>>> be present, but as the corruption also messes with the file(1)
>>> signature,
> some tools like
>>> ldconfig report them as missing.
>> 
>> For reference, the specific messages that were not explicit
>> null-byte complaints were (some shown with a little context):
>> 
>> 
>> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not
>> found
>> ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg
>> 
>> [CA72_ZFS] Installing libxml2-2.10.3_1...
>> [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
>> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found
>> 
>> (/usr/local/lib/libxml2.so) . . .
>> [CA72_ZFS] Extracting libxslt-1.1.37: .. done
>> ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found
>> 
>> (/usr/local/lib/libxslt.so) ===>   Returning to build of
>> py39-lxml-4.9.2
>> . . .
>> ===>  Configuring for py39-lxml-4.9.2
>> Building lxml version 4.9.2.
>> Building with Cython 0.29.33.
>> Error: Please make sure the libxml2 and libxslt development packages
>> are in
> stalled.
>> 
>> 
>> [CA72_ZFS] Extracting libunistring-1.1: .. done
>> ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not
>> found
> 
>> 
>> 
>> [CA72_ZFS] Extracting gmp-6.2.1: .. done
>> ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found
>> 
>> 
>> 
>> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
>> ===>   Installing existing package /packages/All/gmp-6.2.1.pkg
>> [CA72_ZFS] Installing gmp-6.2.1...
>> the most recent version of gmp-6.2.1 is already installed
>> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
>> 
>> *** Error code 1
>> 
>> 
>> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
>> 
>> 
>> checking for GNU
>> M4 that supports accurate traces... configure: error: no acceptable m4
>> coul
> d be found in
>> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is
>> recommended.
>> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
>> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
>> 
>> 
>> ld: error: /usr/local/lib/libblkid.a: unknown file type
>> 
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>> 
>> 
> 
> Hello
> 
> whar is the recent status of fixing/mitigate this desatrous bug?
> Especially f
> or those with the
> new option enabled on ZFS pools. Any advice?
> 
> In an act of precausion (or call it panic) I shutdown several servers to
> prev
> ent irreversible
> damages to databases and data storages. We face on one host with
> /usr/ports r
> esiding on ZFS
> always errors on the same files created while staging (using portmaster,
> leav
> es the system
> with noninstalled software, i.e. www/apache24 in our case). Deleting the
> work
> folder doesn't
> seem to change anything, even when starting a scrubbing of the entire
> pool (R
> AIDZ1 pool) -
> cause unknown, why it affects always the same files to be corrupted.
> Same wit
> h deve/ruby-gems.
> 
> Poudriere has been shutdown for the time being to avoid further issues.
> 
> 
> Are there any advies to proceed apart from conserving the boxes via
> shutdown?
> 
> Thank you ;-)
> oh
> 
> 
> 
> --
> O. Hartmann
 
 With an up-to-date tree + pjd@'s "Fix data corruption when cloning
 embedded
 blocks. #14739" patch I didn't have any 

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mark Millard]

On Apr 15, 2023, at 13:30, Mateusz Guzik  wrote:

> On 4/15/23, FreeBSD User  wrote:
>> Am Sat, 15 Apr 2023 07:36:25 -0700
>> Cy Schubert  schrieb:
>> 
>>> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
>>> FreeBSD Us
>>> er writes:
 Am Thu, 13 Apr 2023 22:18:04 -0700
 Mark Millard  schrieb:
 
> On Apr 13, 2023, at 21:44, Charlie Li  wrote:
> 
>> Mark Millard wrote:
>>> FYI: in my original report for a context that has never had
>>> block_cloning enabled, I reported BOTH missing files and
>>> file content corruption in the poudriere-devel bulk build
>>> testing. This predates:
>>> https://people.freebsd.org/~pjd/patches/brt_revert.patch
>>> but had the changes from:
>>> https://github.com/openzfs/zfs/pull/14739/files
>>> The files were missing from packages installed to be used
>>> during a port's build. No other types of examples of missing
>>> files happened. (But only 11 ports failed.)
>> I also don't have block_cloning enabled. "Missing files" prior to
>> brt_rev
 ert may actually
>> be present, but as the corruption also messes with the file(1)
>> signature,
 some tools like
>> ldconfig report them as missing.
> 
> For reference, the specific messages that were not explicit
> null-byte complaints were (some shown with a little context):
> 
> 
> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not
> found
> ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg
> 
> [CA72_ZFS] Installing libxml2-2.10.3_1...
> [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found
> 
> (/usr/local/lib/libxml2.so) . . .
> [CA72_ZFS] Extracting libxslt-1.1.37: .. done
> ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found
> 
> (/usr/local/lib/libxslt.so) ===>   Returning to build of
> py39-lxml-4.9.2
> . . .
> ===>  Configuring for py39-lxml-4.9.2
> Building lxml version 4.9.2.
> Building with Cython 0.29.33.
> Error: Please make sure the libxml2 and libxslt development packages
> are in
 stalled.
> 
> 
> [CA72_ZFS] Extracting libunistring-1.1: .. done
> ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not
> found
 
> 
> 
> [CA72_ZFS] Extracting gmp-6.2.1: .. done
> ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found
> 
> 
> 
> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> ===>   Installing existing package /packages/All/gmp-6.2.1.pkg
> [CA72_ZFS] Installing gmp-6.2.1...
> the most recent version of gmp-6.2.1 is already installed
> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> 
> *** Error code 1
> 
> 
> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> 
> 
> checking for GNU
> M4 that supports accurate traces... configure: error: no acceptable m4
> coul
 d be found in
> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is
> recommended.
> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> 
> 
> ld: error: /usr/local/lib/libblkid.a: unknown file type
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 
 
 Hello
 
 whar is the recent status of fixing/mitigate this desatrous bug?
 Especially f
 or those with the
 new option enabled on ZFS pools. Any advice?
 
 In an act of precausion (or call it panic) I shutdown several servers to
 prev
 ent irreversible
 damages to databases and data storages. We face on one host with
 /usr/ports r
 esiding on ZFS
 always errors on the same files created while staging (using portmaster,
 leav
 es the system
 with noninstalled software, i.e. www/apache24 in our case). Deleting the
 work
 folder doesn't
 seem to change anything, even when starting a scrubbing of the entire
 pool (R
 AIDZ1 pool) -
 cause unknown, why it affects always the same files to be corrupted.
 Same wit
 h deve/ruby-gems.
 
 Poudriere has been shutdown for the time being to avoid further issues.
 
 
 Are there any advies to proceed apart from conserving the boxes via
 shutdown?
 
 Thank you ;-)
 oh
 
 
 
 --
 O. Hartmann
>>> 
>>> With an up-to-date tree + pjd@'s "Fix data corruption when cloning
>>> embedded
>>> blocks. #14739" patch I didn't have any issues, except for email messages
>>> 
>>> with corruption in my sent directory, nowhere else. I'm still
>>> investigating
>>> the email messages issue. IMO one is generally safe to run poudriere on
>>> 

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mateusz Guzik]

On 4/15/23, FreeBSD User  wrote:
> Am Sat, 15 Apr 2023 07:36:25 -0700
> Cy Schubert  schrieb:
>
>> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
>> FreeBSD Us
>> er writes:
>> > Am Thu, 13 Apr 2023 22:18:04 -0700
>> > Mark Millard  schrieb:
>> >
>> > > On Apr 13, 2023, at 21:44, Charlie Li  wrote:
>> > >
>> > > > Mark Millard wrote:
>> > > >> FYI: in my original report for a context that has never had
>> > > >> block_cloning enabled, I reported BOTH missing files and
>> > > >> file content corruption in the poudriere-devel bulk build
>> > > >> testing. This predates:
>> > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch
>> > > >> but had the changes from:
>> > > >> https://github.com/openzfs/zfs/pull/14739/files
>> > > >> The files were missing from packages installed to be used
>> > > >> during a port's build. No other types of examples of missing
>> > > >> files happened. (But only 11 ports failed.)
>> > > > I also don't have block_cloning enabled. "Missing files" prior to
>> > > > brt_rev
>> > ert may actually
>> > > > be present, but as the corruption also messes with the file(1)
>> > > > signature,
>> >  some tools like
>> > > > ldconfig report them as missing.
>> > >
>> > > For reference, the specific messages that were not explicit
>> > > null-byte complaints were (some shown with a little context):
>> > >
>> > >
>> > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not
>> > > found
>> > > ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg
>> > >
>> > > [CA72_ZFS] Installing libxml2-2.10.3_1...
>> > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
>> > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found
>> > >
>> > > (/usr/local/lib/libxml2.so) . . .
>> > > [CA72_ZFS] Extracting libxslt-1.1.37: .. done
>> > > ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found
>> > >
>> > > (/usr/local/lib/libxslt.so) ===>   Returning to build of
>> > > py39-lxml-4.9.2
>> > > . . .
>> > > ===>  Configuring for py39-lxml-4.9.2
>> > > Building lxml version 4.9.2.
>> > > Building with Cython 0.29.33.
>> > > Error: Please make sure the libxml2 and libxslt development packages
>> > > are in
>> > stalled.
>> > >
>> > >
>> > > [CA72_ZFS] Extracting libunistring-1.1: .. done
>> > > ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not
>> > > found
>> >
>> > >
>> > >
>> > > [CA72_ZFS] Extracting gmp-6.2.1: .. done
>> > > ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found
>> > >
>> > >
>> > >
>> > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
>> > > ===>   Installing existing package /packages/All/gmp-6.2.1.pkg
>> > > [CA72_ZFS] Installing gmp-6.2.1...
>> > > the most recent version of gmp-6.2.1 is already installed
>> > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
>> > >
>> > > *** Error code 1
>> > >
>> > >
>> > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
>> > >
>> > >
>> > > checking for GNU
>> > > M4 that supports accurate traces... configure: error: no acceptable m4
>> > > coul
>> > d be found in
>> > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is
>> > > recommended.
>> > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
>> > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
>> > >
>> > >
>> > > ld: error: /usr/local/lib/libblkid.a: unknown file type
>> > >
>> > >
>> > > ===
>> > > Mark Millard
>> > > marklmi at yahoo.com
>> > >
>> > >
>> >
>> > Hello
>> >
>> > whar is the recent status of fixing/mitigate this desatrous bug?
>> > Especially f
>> > or those with the
>> > new option enabled on ZFS pools. Any advice?
>> >
>> > In an act of precausion (or call it panic) I shutdown several servers to
>> > prev
>> > ent irreversible
>> > damages to databases and data storages. We face on one host with
>> > /usr/ports r
>> > esiding on ZFS
>> > always errors on the same files created while staging (using portmaster,
>> > leav
>> > es the system
>> > with noninstalled software, i.e. www/apache24 in our case). Deleting the
>> > work
>> >  folder doesn't
>> > seem to change anything, even when starting a scrubbing of the entire
>> > pool (R
>> > AIDZ1 pool) -
>> > cause unknown, why it affects always the same files to be corrupted.
>> > Same wit
>> > h deve/ruby-gems.
>> >
>> > Poudriere has been shutdown for the time being to avoid further issues.
>> >
>> >
>> > Are there any advies to proceed apart from conserving the boxes via
>> > shutdown?
>> >
>> > Thank you ;-)
>> > oh
>> >
>> >
>> >
>> > --
>> > O. Hartmann
>>
>> With an up-to-date tree + pjd@'s "Fix data corruption when cloning
>> embedded
>> blocks. #14739" patch I didn't have any issues, except for email messages
>>
>> with corruption in my sent directory, nowhere else. I'm still
>> investigating
>> the email messages issue. IMO one is generally safe to run poudriere on
>> the

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mark Millard]

On Apr 15, 2023, at 11:07, Cy Schubert  wrote:

> In message <5a47f62d-0e78-4c3e-84c0-45eeb03c7...@yahoo.com>, Mark Millard 
> write
> s:
>> On Apr 15, 2023, at 07:36, Cy Schubert  =
>> wrote:
>> 
>>> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,=20=
>> 
>>> FreeBSD Us
>>> er writes:
 Am Thu, 13 Apr 2023 22:18:04 -0700
 Mark Millard  schrieb:
 =20
> On Apr 13, 2023, at 21:44, Charlie Li  wrote:
> =20
>> Mark Millard wrote: =20
>>> FYI: in my original report for a context that has never had
>>> block_cloning enabled, I reported BOTH missing files and
>>> file content corruption in the poudriere-devel bulk build
>>> testing. This predates:
>>> https://people.freebsd.org/~pjd/patches/brt_revert.patch
>>> but had the changes from:
>>> https://github.com/openzfs/zfs/pull/14739/files
>>> The files were missing from packages installed to be used
>>> during a port's build. No other types of examples of missing
>>> files happened. (But only 11 ports failed.) =20
>> I also don't have block_cloning enabled. "Missing files" prior to =
>> brt_rev
 ert may actually
>> be present, but as the corruption also messes with the file(1) =
>> signature,
 some tools like
>> ldconfig report them as missing. =20
> =20
> For reference, the specific messages that were not explicit
> null-byte complaints were (some shown with a little context):
> =20
> =20
> =3D=3D=3D>   py39-lxml-4.9.2 depends on shared library: libxml2.so - =
>> not found
> =3D=3D=3D>   Installing existing package =
>> /packages/All/libxml2-2.10.3_1.pkg =20
> [CA72_ZFS] Installing libxml2-2.10.3_1...
> [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
> =3D=3D=3D>   py39-lxml-4.9.2 depends on shared library: libxml2.so - =
>> found
> (/usr/local/lib/libxml2.so) . . .
> [CA72_ZFS] Extracting libxslt-1.1.37: .. done
> =3D=3D=3D>   py39-lxml-4.9.2 depends on shared library: libxslt.so - =
>> found
> (/usr/local/lib/libxslt.so) =3D=3D=3D>   Returning to build of =
>> py39-lxml-4.9.2 =20
> . . .
> =3D=3D=3D>  Configuring for py39-lxml-4.9.2 =20
> Building lxml version 4.9.2.
> Building with Cython 0.29.33.
> Error: Please make sure the libxml2 and libxslt development packages =
>> are in
 stalled.
> =20
> =20
> [CA72_ZFS] Extracting libunistring-1.1: .. done
> =3D=3D=3D>   libidn2-2.3.4 depends on shared library: =
>> libunistring.so - not found
 =20
> =20
> =20
> [CA72_ZFS] Extracting gmp-6.2.1: .. done
> =3D=3D=3D>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not =
>> found =20
> =20
> =20
> =3D=3D=3D>   nettle-3.8.1 depends on shared library: libgmp.so - not =
>> found
> =3D=3D=3D>   Installing existing package /packages/All/gmp-6.2.1.pkg =
>> =20
> [CA72_ZFS] Installing gmp-6.2.1...
> the most recent version of gmp-6.2.1 is already installed
> =3D=3D=3D>   nettle-3.8.1 depends on shared library: libgmp.so - not =
>> found =20
> *** Error code 1
> =20
> =20
> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> =20
> =20
> checking for GNU=20
> M4 that supports accurate traces... configure: error: no acceptable =
>> m4 coul
 d be found in
> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is =
>> recommended.
> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> =20
> =20
> ld: error: /usr/local/lib/libblkid.a: unknown file type
> =20
> =20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
> =20
> =20
 =20
 Hello=20
 =20
 whar is the recent status of fixing/mitigate this desatrous bug? =
>> Especially f
 or those with the
 new option enabled on ZFS pools. Any advice?
 =20
 In an act of precausion (or call it panic) I shutdown several servers =
>> to prev
 ent irreversible
 damages to databases and data storages. We face on one host with =
>> /usr/ports r
 esiding on ZFS
 always errors on the same files created while staging (using =
>> portmaster, leav
 es the system
 with noninstalled software, i.e. www/apache24 in our case). Deleting =
>> the work
 folder doesn't
 seem to change anything, even when starting a scrubbing of the entire =
>> pool (R
 AIDZ1 pool) -
 cause unknown, why it affects always the same files to be corrupted. =
>> Same wit
 h deve/ruby-gems.
 =20
 Poudriere has been shutdown for the time being to avoid further =
>> issues.=20
 =20
 Are there any advies to proceed apart from conserving the boxes via =
>> shutdown?
 =20
 Thank you ;-)
 oh
 =20
 =20
 =20
 --=20
 O. Hartmann
>>> =20
>>> With an up-to-date tree + pjd@'s "Fix data corruption when cloning =

Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!]

[Graham Perrin]

On 14/04/2023 11:58, Mark Millard wrote:

… zfs after the import corrupts data even without block_cloning having ever 
been in use, even as the code currently is. …



 
(2023-04-12) discusses reported corruptions when block cloning was 
disabled; "… Not a data corruption inside ZFS. …".


HTH (I have not followed the parallel discussions in depth)



OpenPGP_signature
Description: OpenPGP digital signature

Re: OpenZFS recently (was … [zfs corruptions without block_cloning involved!])

[Warner Losh]

On Sat, Apr 15, 2023, 11:56 AM Graham Perrin 
wrote:

> On 15/04/2023 14:41, void wrote:
> > On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote:
> >>
> >> Is the recent situation unusual enough to warrant an entry in UPDATING?
> >>
> >
> > yeah I'd say so.
> >
> > Also does this affect 13-stable and the recent 13.2-RELEASE or just
> > -current?
>
>
> If I'm looking in the right place:
>
>  to main on
> 2023-04-03, "zfs: merge openzfs/zfs@431083f75"
>
>  no
> comparable merge to stable/13.
>


Correct. The change isn't in the branch stable/13 tracks.

Warner

>

Re: OpenZFS recently (was … [zfs corruptions without block_cloning involved!])

[Christos Chatzaras]

> On 15 Apr 2023, at 20:56, Graham Perrin  wrote:
> 
> On 15/04/2023 14:41, void wrote:
>> On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote:
>>> 
>>> Is the recent situation unusual enough to warrant an entry in UPDATING?
>>> 
>> 
>> yeah I'd say so.
>> 
>> Also does this affect 13-stable and the recent 13.2-RELEASE or just -current?
> 
> 
> If I'm looking in the right place:
> 
>  to main on 
> 2023-04-03, "zfs: merge openzfs/zfs@431083f75"
> 
>  no 
> comparable merge to stable/13.
> 

Looks like only CURRENT is affected.

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Cy Schubert]

In message <5a47f62d-0e78-4c3e-84c0-45eeb03c7...@yahoo.com>, Mark Millard 
write
s:
> On Apr 15, 2023, at 07:36, Cy Schubert  =
> wrote:
>
> > In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,=20=
>
> > FreeBSD Us
> > er writes:
> >> Am Thu, 13 Apr 2023 22:18:04 -0700
> >> Mark Millard  schrieb:
> >>=20
> >>> On Apr 13, 2023, at 21:44, Charlie Li  wrote:
> >>>=20
>  Mark Millard wrote: =20
> > FYI: in my original report for a context that has never had
> > block_cloning enabled, I reported BOTH missing files and
> > file content corruption in the poudriere-devel bulk build
> > testing. This predates:
> > https://people.freebsd.org/~pjd/patches/brt_revert.patch
> > but had the changes from:
> > https://github.com/openzfs/zfs/pull/14739/files
> > The files were missing from packages installed to be used
> > during a port's build. No other types of examples of missing
> > files happened. (But only 11 ports failed.) =20
>  I also don't have block_cloning enabled. "Missing files" prior to =
> brt_rev
> >> ert may actually
>  be present, but as the corruption also messes with the file(1) =
> signature,
> >> some tools like
>  ldconfig report them as missing. =20
> >>>=20
> >>> For reference, the specific messages that were not explicit
> >>> null-byte complaints were (some shown with a little context):
> >>>=20
> >>>=20
> >>> =3D=3D=3D>   py39-lxml-4.9.2 depends on shared library: libxml2.so - =
> not found
> >>> =3D=3D=3D>   Installing existing package =
> /packages/All/libxml2-2.10.3_1.pkg =20
> >>> [CA72_ZFS] Installing libxml2-2.10.3_1...
> >>> [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
> >>> =3D=3D=3D>   py39-lxml-4.9.2 depends on shared library: libxml2.so - =
> found
> >>> (/usr/local/lib/libxml2.so) . . .
> >>> [CA72_ZFS] Extracting libxslt-1.1.37: .. done
> >>> =3D=3D=3D>   py39-lxml-4.9.2 depends on shared library: libxslt.so - =
> found
> >>> (/usr/local/lib/libxslt.so) =3D=3D=3D>   Returning to build of =
> py39-lxml-4.9.2 =20
> >>> . . .
> >>> =3D=3D=3D>  Configuring for py39-lxml-4.9.2 =20
> >>> Building lxml version 4.9.2.
> >>> Building with Cython 0.29.33.
> >>> Error: Please make sure the libxml2 and libxslt development packages =
> are in
> >> stalled.
> >>>=20
> >>>=20
> >>> [CA72_ZFS] Extracting libunistring-1.1: .. done
> >>> =3D=3D=3D>   libidn2-2.3.4 depends on shared library: =
> libunistring.so - not found
> >>=20
> >>>=20
> >>>=20
> >>> [CA72_ZFS] Extracting gmp-6.2.1: .. done
> >>> =3D=3D=3D>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not =
> found =20
> >>>=20
> >>>=20
> >>> =3D=3D=3D>   nettle-3.8.1 depends on shared library: libgmp.so - not =
> found
> >>> =3D=3D=3D>   Installing existing package /packages/All/gmp-6.2.1.pkg =
> =20
> >>> [CA72_ZFS] Installing gmp-6.2.1...
> >>> the most recent version of gmp-6.2.1 is already installed
> >>> =3D=3D=3D>   nettle-3.8.1 depends on shared library: libgmp.so - not =
> found =20
> >>> *** Error code 1
> >>>=20
> >>>=20
> >>> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> >>>=20
> >>>=20
> >>> checking for GNU=20
> >>> M4 that supports accurate traces... configure: error: no acceptable =
> m4 coul
> >> d be found in
> >>> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is =
> recommended.
> >>> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> >>> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> >>>=20
> >>>=20
> >>> ld: error: /usr/local/lib/libblkid.a: unknown file type
> >>>=20
> >>>=20
> >>> =3D=3D=3D
> >>> Mark Millard
> >>> marklmi at yahoo.com
> >>>=20
> >>>=20
> >>=20
> >> Hello=20
> >>=20
> >> whar is the recent status of fixing/mitigate this desatrous bug? =
> Especially f
> >> or those with the
> >> new option enabled on ZFS pools. Any advice?
> >>=20
> >> In an act of precausion (or call it panic) I shutdown several servers =
> to prev
> >> ent irreversible
> >> damages to databases and data storages. We face on one host with =
> /usr/ports r
> >> esiding on ZFS
> >> always errors on the same files created while staging (using =
> portmaster, leav
> >> es the system
> >> with noninstalled software, i.e. www/apache24 in our case). Deleting =
> the work
> >> folder doesn't
> >> seem to change anything, even when starting a scrubbing of the entire =
> pool (R
> >> AIDZ1 pool) -
> >> cause unknown, why it affects always the same files to be corrupted. =
> Same wit
> >> h deve/ruby-gems.
> >>=20
> >> Poudriere has been shutdown for the time being to avoid further =
> issues.=20
> >>=20
> >> Are there any advies to proceed apart from conserving the boxes via =
> shutdown?
> >>=20
> >> Thank you ;-)
> >> oh
> >>=20
> >>=20
> >>=20
> >> --=20
> >> O. Hartmann
> >=20
> > With an up-to-date tree + pjd@'s "Fix data corruption when cloning =
> embedded=20
> > blocks. #14739" patch I didn't have any issues, except for email =
> messages=20
> > with 

Re: OpenZFS recently (was … [zfs corruptions without block_cloning involved!])

[Graham Perrin]

On 15/04/2023 14:41, void wrote:

On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote:


Is the recent situation unusual enough to warrant an entry in UPDATING?



yeah I'd say so.

Also does this affect 13-stable and the recent 13.2-RELEASE or just 
-current?



If I'm looking in the right place:

 to main on 
2023-04-03, "zfs: merge openzfs/zfs@431083f75"


 no 
comparable merge to stable/13.




OpenPGP_signature
Description: OpenPGP digital signature

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Mark Millard]

On Apr 15, 2023, at 07:36, Cy Schubert  wrote:

> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>, 
> FreeBSD Us
> er writes:
>> Am Thu, 13 Apr 2023 22:18:04 -0700
>> Mark Millard  schrieb:
>> 
>>> On Apr 13, 2023, at 21:44, Charlie Li  wrote:
>>> 
 Mark Millard wrote:  
> FYI: in my original report for a context that has never had
> block_cloning enabled, I reported BOTH missing files and
> file content corruption in the poudriere-devel bulk build
> testing. This predates:
> https://people.freebsd.org/~pjd/patches/brt_revert.patch
> but had the changes from:
> https://github.com/openzfs/zfs/pull/14739/files
> The files were missing from packages installed to be used
> during a port's build. No other types of examples of missing
> files happened. (But only 11 ports failed.)  
 I also don't have block_cloning enabled. "Missing files" prior to brt_rev
>> ert may actually
 be present, but as the corruption also messes with the file(1) signature,
>> some tools like
 ldconfig report them as missing.  
>>> 
>>> For reference, the specific messages that were not explicit
>>> null-byte complaints were (some shown with a little context):
>>> 
>>> 
>>> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not found
>>> ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg  
>>> [CA72_ZFS] Installing libxml2-2.10.3_1...
>>> [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
>>> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found
>>> (/usr/local/lib/libxml2.so) . . .
>>> [CA72_ZFS] Extracting libxslt-1.1.37: .. done
>>> ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found
>>> (/usr/local/lib/libxslt.so) ===>   Returning to build of py39-lxml-4.9.2  
>>> . . .
>>> ===>  Configuring for py39-lxml-4.9.2  
>>> Building lxml version 4.9.2.
>>> Building with Cython 0.29.33.
>>> Error: Please make sure the libxml2 and libxslt development packages are in
>> stalled.
>>> 
>>> 
>>> [CA72_ZFS] Extracting libunistring-1.1: .. done
>>> ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not found
>> 
>>> 
>>> 
>>> [CA72_ZFS] Extracting gmp-6.2.1: .. done
>>> ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found  
>>> 
>>> 
>>> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
>>> ===>   Installing existing package /packages/All/gmp-6.2.1.pkg  
>>> [CA72_ZFS] Installing gmp-6.2.1...
>>> the most recent version of gmp-6.2.1 is already installed
>>> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found  
>>> *** Error code 1
>>> 
>>> 
>>> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
>>> 
>>> 
>>> checking for GNU 
>>> M4 that supports accurate traces... configure: error: no acceptable m4 coul
>> d be found in
>>> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
>>> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
>>> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
>>> 
>>> 
>>> ld: error: /usr/local/lib/libblkid.a: unknown file type
>>> 
>>> 
>>> ===
>>> Mark Millard
>>> marklmi at yahoo.com
>>> 
>>> 
>> 
>> Hello 
>> 
>> whar is the recent status of fixing/mitigate this desatrous bug? Especially f
>> or those with the
>> new option enabled on ZFS pools. Any advice?
>> 
>> In an act of precausion (or call it panic) I shutdown several servers to prev
>> ent irreversible
>> damages to databases and data storages. We face on one host with /usr/ports r
>> esiding on ZFS
>> always errors on the same files created while staging (using portmaster, leav
>> es the system
>> with noninstalled software, i.e. www/apache24 in our case). Deleting the work
>> folder doesn't
>> seem to change anything, even when starting a scrubbing of the entire pool (R
>> AIDZ1 pool) -
>> cause unknown, why it affects always the same files to be corrupted. Same wit
>> h deve/ruby-gems.
>> 
>> Poudriere has been shutdown for the time being to avoid further issues. 
>> 
>> Are there any advies to proceed apart from conserving the boxes via shutdown?
>> 
>> Thank you ;-)
>> oh
>> 
>> 
>> 
>> -- 
>> O. Hartmann
> 
> With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded 
> blocks. #14739" patch I didn't have any issues, except for email messages 
> with corruption in my sent directory, nowhere else. I'm still investigating 
> the email messages issue. IMO one is generally safe to run poudriere on the 
> latest ZFS with the additional patch.

My poudriere testing failed when I tested such (14739 included),
per what I reported, block_cloning never have been enabled.
Others have also reported poudriere bulk build failures absent
block_cloning being involved and 14739 being in place. My tests
do predate:

https://people.freebsd.org/~pjd/patches/brt_revert.patch

and I'm not sure of if Cy's activity had brt_revert.patch in
place or not.

Other's notes 

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Cy Schubert]

On Sat, 15 Apr 2023 18:07:34 +0200
Florian Smeets  wrote:

> On 15.04.23 17:51, FreeBSD User wrote:
> > Am Sat, 15 Apr 2023 07:36:25 -0700
> > Cy Schubert  schrieb:  
> >>
> >> With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded
> >> blocks. #14739" patch I didn't have any issues, except for email messages
> >> with corruption in my sent directory, nowhere else. I'm still investigating
> >> the email messages issue. IMO one is generally safe to run poudriere on the
> >> latest ZFS with the additional patch.  
> 
> This is also my current observation. I have 2 hosts where I was 
> unfortunate enough to update at the wrong time. I currently *think* that 
> I'm *not* seeing data corruption with head from April 12th and this 
> patch 
> https://github.com/openzfs/zfs/commit/d3a6e5ca3b2f684132238ca968bf0b96f17ec7e1.diff
>  
> applied.
> 
> One pool has been upgraded with feature@block_cloning and the other hasn't.
> > 
> > FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 07:57:16 CEST 
> > 2023 amd64
> > 
> > The box is crashing while trying to update ports with the well known issue:
> > 
> > Panic String: VERIFY(!zil_replaying(zilog, tx)) failed
> >   
> On the pool that has block_cloning enabled I see the above insta panic 
> when poudriere starts building. I found a workaround though:
> 
> --- /usr/local/share/poudriere/include/fs.sh.orig 2023-04-15 
> 18:03:50.090823000 +0200
> +++ /usr/local/share/poudriere/include/fs.sh  2023-04-15 
> 18:04:04.144736000 +0200
> @@ -295,7 +295,6 @@
>   fi
> 
>   zfs clone -o mountpoint=${mnt} \
> - -o sync=disabled \
>   -o atime=off \
>   -o compression=off \
>   ${fs}@${snap} \
> 
> With this workaround I was able to build thousands of packages without 
> panics or failures due to data corruption.

Thanks for this. I'll test this next week. A one should be able to test
this by hand to capture a dump.

> 
> Florian



-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Cy Schubert]

In message <20230415175218.777d0...@thor.intern.walstatt.dynvpn.de>, 
FreeBSD Us
er writes:
> Am Sat, 15 Apr 2023 07:36:25 -0700
> Cy Schubert  schrieb:
>
> > In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>, 
> > FreeBSD Us
> > er writes:
> > > Am Thu, 13 Apr 2023 22:18:04 -0700
> > > Mark Millard  schrieb:
> > >  
> > > > On Apr 13, 2023, at 21:44, Charlie Li  wrote:
> > > >   
> > > > > Mark Millard wrote:
> > > > >> FYI: in my original report for a context that has never had
> > > > >> block_cloning enabled, I reported BOTH missing files and
> > > > >> file content corruption in the poudriere-devel bulk build
> > > > >> testing. This predates:
> > > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch
> > > > >> but had the changes from:
> > > > >> https://github.com/openzfs/zfs/pull/14739/files
> > > > >> The files were missing from packages installed to be used
> > > > >> during a port's build. No other types of examples of missing
> > > > >> files happened. (But only 11 ports failed.)
> > > > > I also don't have block_cloning enabled. "Missing files" prior to brt
> _rev  
> > > ert may actually  
> > > > > be present, but as the corruption also messes with the file(1) signat
> ure,  
> > >  some tools like  
> > > > > ldconfig report them as missing.
> > > > 
> > > > For reference, the specific messages that were not explicit
> > > > null-byte complaints were (some shown with a little context):
> > > > 
> > > >   
> > > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not foun
> d
> > > > ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg  
>   
> > > > [CA72_ZFS] Installing libxml2-2.10.3_1...
> > > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done  
> > > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found  
> > > > (/usr/local/lib/libxml2.so) . . .
> > > > [CA72_ZFS] Extracting libxslt-1.1.37: .. done  
> > > > ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found  
> > > > (/usr/local/lib/libxslt.so) ===>   Returning to build of py39-lxml-4.9.
> 2  
> > > > . . .  
> > > > ===>  Configuring for py39-lxml-4.9.2
> > > > Building lxml version 4.9.2.
> > > > Building with Cython 0.29.33.
> > > > Error: Please make sure the libxml2 and libxslt development packages ar
> e in  
> > > stalled.  
> > > > 
> > > > 
> > > > [CA72_ZFS] Extracting libunistring-1.1: .. done  
> > > > ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not f
> ound  
> > > 
> > > > 
> > > > 
> > > > [CA72_ZFS] Extracting gmp-6.2.1: .. done  
> > > > ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found   
>  
> > > > 
> > > >   
> > > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> > > > ===>   Installing existing package /packages/All/gmp-6.2.1.pkg
> > > > [CA72_ZFS] Installing gmp-6.2.1...
> > > > the most recent version of gmp-6.2.1 is already installed  
> > > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found   
>  
> > > > *** Error code 1
> > > > 
> > > > 
> > > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> > > > 
> > > > 
> > > > checking for GNU 
> > > > M4 that supports accurate traces... configure: error: no acceptable m4 
> coul  
> > > d be found in  
> > > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommende
> d.
> > > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> > > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> > > > 
> > > > 
> > > > ld: error: /usr/local/lib/libblkid.a: unknown file type
> > > > 
> > > > 
> > > > ===
> > > > Mark Millard
> > > > marklmi at yahoo.com
> > > > 
> > > >   
> > >
> > > Hello 
> > >
> > > whar is the recent status of fixing/mitigate this desatrous bug? Especial
> ly f
> > > or those with the
> > > new option enabled on ZFS pools. Any advice?
> > >
> > > In an act of precausion (or call it panic) I shutdown several servers to 
> prev
> > > ent irreversible
> > > damages to databases and data storages. We face on one host with /usr/por
> ts r
> > > esiding on ZFS
> > > always errors on the same files created while staging (using portmaster, 
> leav
> > > es the system
> > > with noninstalled software, i.e. www/apache24 in our case). Deleting the 
> work
> > >  folder doesn't
> > > seem to change anything, even when starting a scrubbing of the entire poo
> l (R
> > > AIDZ1 pool) -
> > > cause unknown, why it affects always the same files to be corrupted. Same
>  wit
> > > h deve/ruby-gems.
> > >
> > > Poudriere has been shutdown for the time being to avoid further issues. 
> > >
> > > Are there any advies to proceed apart from conserving the boxes via shutd
> own?
> > >
> > > Thank you ;-)
> > > oh
> > >
> > >
> > >
> > > -- 
> > > O. Hartmann  
> > 
> > With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded
>  
> > blocks. #14739" patch I didn't have 

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Florian Smeets]

On 15.04.23 17:51, FreeBSD User wrote:

Am Sat, 15 Apr 2023 07:36:25 -0700
Cy Schubert  schrieb:


With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded
blocks. #14739" patch I didn't have any issues, except for email messages
with corruption in my sent directory, nowhere else. I'm still investigating
the email messages issue. IMO one is generally safe to run poudriere on the
latest ZFS with the additional patch.


This is also my current observation. I have 2 hosts where I was 
unfortunate enough to update at the wrong time. I currently *think* that 
I'm *not* seeing data corruption with head from April 12th and this 
patch 
https://github.com/openzfs/zfs/commit/d3a6e5ca3b2f684132238ca968bf0b96f17ec7e1.diff 
applied.


One pool has been upgraded with feature@block_cloning and the other hasn't.


FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 07:57:16 CEST 
2023 amd64

The box is crashing while trying to update ports with the well known issue:

Panic String: VERIFY(!zil_replaying(zilog, tx)) failed

On the pool that has block_cloning enabled I see the above insta panic 
when poudriere starts building. I found a workaround though:


--- /usr/local/share/poudriere/include/fs.sh.orig	2023-04-15 
18:03:50.090823000 +0200
+++ /usr/local/share/poudriere/include/fs.sh	2023-04-15 
18:04:04.144736000 +0200

@@ -295,7 +295,6 @@
fi

zfs clone -o mountpoint=${mnt} \
-   -o sync=disabled \
-o atime=off \
-o compression=off \
${fs}@${snap} \

With this workaround I was able to build thousands of packages without 
panics or failures due to data corruption.


Florian


OpenPGP_0xEF5BA4DCD5A9F3C0.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[FreeBSD User]

Am Sat, 15 Apr 2023 07:36:25 -0700
Cy Schubert  schrieb:

> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>, 
> FreeBSD Us
> er writes:
> > Am Thu, 13 Apr 2023 22:18:04 -0700
> > Mark Millard  schrieb:
> >  
> > > On Apr 13, 2023, at 21:44, Charlie Li  wrote:
> > >   
> > > > Mark Millard wrote:
> > > >> FYI: in my original report for a context that has never had
> > > >> block_cloning enabled, I reported BOTH missing files and
> > > >> file content corruption in the poudriere-devel bulk build
> > > >> testing. This predates:
> > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch
> > > >> but had the changes from:
> > > >> https://github.com/openzfs/zfs/pull/14739/files
> > > >> The files were missing from packages installed to be used
> > > >> during a port's build. No other types of examples of missing
> > > >> files happened. (But only 11 ports failed.)
> > > > I also don't have block_cloning enabled. "Missing files" prior to 
> > > > brt_rev  
> > ert may actually  
> > > > be present, but as the corruption also messes with the file(1) 
> > > > signature,  
> >  some tools like  
> > > > ldconfig report them as missing.
> > > 
> > > For reference, the specific messages that were not explicit
> > > null-byte complaints were (some shown with a little context):
> > > 
> > >   
> > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not found
> > > ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg
> > > [CA72_ZFS] Installing libxml2-2.10.3_1...
> > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done  
> > > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found  
> > > (/usr/local/lib/libxml2.so) . . .
> > > [CA72_ZFS] Extracting libxslt-1.1.37: .. done  
> > > ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found  
> > > (/usr/local/lib/libxslt.so) ===>   Returning to build of py39-lxml-4.9.2  
> > > . . .  
> > > ===>  Configuring for py39-lxml-4.9.2
> > > Building lxml version 4.9.2.
> > > Building with Cython 0.29.33.
> > > Error: Please make sure the libxml2 and libxslt development packages are 
> > > in  
> > stalled.  
> > > 
> > > 
> > > [CA72_ZFS] Extracting libunistring-1.1: .. done  
> > > ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not 
> > > found  
> > 
> > > 
> > > 
> > > [CA72_ZFS] Extracting gmp-6.2.1: .. done  
> > > ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found
> > > 
> > >   
> > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> > > ===>   Installing existing package /packages/All/gmp-6.2.1.pkg
> > > [CA72_ZFS] Installing gmp-6.2.1...
> > > the most recent version of gmp-6.2.1 is already installed  
> > > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> > > *** Error code 1
> > > 
> > > 
> > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> > > 
> > > 
> > > checking for GNU 
> > > M4 that supports accurate traces... configure: error: no acceptable m4 
> > > coul  
> > d be found in  
> > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
> > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> > > 
> > > 
> > > ld: error: /usr/local/lib/libblkid.a: unknown file type
> > > 
> > > 
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> > > 
> > >   
> >
> > Hello 
> >
> > whar is the recent status of fixing/mitigate this desatrous bug? Especially 
> > f
> > or those with the
> > new option enabled on ZFS pools. Any advice?
> >
> > In an act of precausion (or call it panic) I shutdown several servers to 
> > prev
> > ent irreversible
> > damages to databases and data storages. We face on one host with /usr/ports 
> > r
> > esiding on ZFS
> > always errors on the same files created while staging (using portmaster, 
> > leav
> > es the system
> > with noninstalled software, i.e. www/apache24 in our case). Deleting the 
> > work
> >  folder doesn't
> > seem to change anything, even when starting a scrubbing of the entire pool 
> > (R
> > AIDZ1 pool) -
> > cause unknown, why it affects always the same files to be corrupted. Same 
> > wit
> > h deve/ruby-gems.
> >
> > Poudriere has been shutdown for the time being to avoid further issues. 
> >
> > Are there any advies to proceed apart from conserving the boxes via 
> > shutdown?
> >
> > Thank you ;-)
> > oh
> >
> >
> >
> > -- 
> > O. Hartmann  
> 
> With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded 
> blocks. #14739" patch I didn't have any issues, except for email messages 
> with corruption in my sent directory, nowhere else. I'm still investigating 
> the email messages issue. IMO one is generally safe to run poudriere on the 
> latest ZFS with the additional patch.
> 
> My tests of the additional patch concluded that it resolved my last 

Re: Status of Alder and Raptor lake on FreeBSD Current

[Alexey Vyskubov]

> I was wondering what the status of Alder/Raptor lake support is on FreeBSD?
> Does it boot?

I am writing this message from 13.2 machine with i3-12100F (must be an
Alder Lake; no integrated graphics in this one, though) in B660
motherboard. Previously the same machine was running 13.1. If it
matters, I have multiple ZFS pools, including root on ZFS mirror.
According to powermon(8) my package normally consumes less than 10W.

I do not think that the support for an Alder Lake got worse in -CURRENT.

-- 
Alexey

I cannot receive HTML mail at this account.

Hi, I am a signature virus. Add me to your signature to help me spread.

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[Cy Schubert]

In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>, 
FreeBSD Us
er writes:
> Am Thu, 13 Apr 2023 22:18:04 -0700
> Mark Millard  schrieb:
>
> > On Apr 13, 2023, at 21:44, Charlie Li  wrote:
> > 
> > > Mark Millard wrote:  
> > >> FYI: in my original report for a context that has never had
> > >> block_cloning enabled, I reported BOTH missing files and
> > >> file content corruption in the poudriere-devel bulk build
> > >> testing. This predates:
> > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch
> > >> but had the changes from:
> > >> https://github.com/openzfs/zfs/pull/14739/files
> > >> The files were missing from packages installed to be used
> > >> during a port's build. No other types of examples of missing
> > >> files happened. (But only 11 ports failed.)  
> > > I also don't have block_cloning enabled. "Missing files" prior to brt_rev
> ert may actually
> > > be present, but as the corruption also messes with the file(1) signature,
>  some tools like
> > > ldconfig report them as missing.  
> > 
> > For reference, the specific messages that were not explicit
> > null-byte complaints were (some shown with a little context):
> > 
> > 
> > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not found
> > ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg  
> > [CA72_ZFS] Installing libxml2-2.10.3_1...
> > [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
> > ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found
> > (/usr/local/lib/libxml2.so) . . .
> > [CA72_ZFS] Extracting libxslt-1.1.37: .. done
> > ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found
> > (/usr/local/lib/libxslt.so) ===>   Returning to build of py39-lxml-4.9.2  
> > . . .
> > ===>  Configuring for py39-lxml-4.9.2  
> > Building lxml version 4.9.2.
> > Building with Cython 0.29.33.
> > Error: Please make sure the libxml2 and libxslt development packages are in
> stalled.
> > 
> > 
> > [CA72_ZFS] Extracting libunistring-1.1: .. done
> > ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not found
>   
> > 
> > 
> > [CA72_ZFS] Extracting gmp-6.2.1: .. done
> > ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found  
> > 
> > 
> > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> > ===>   Installing existing package /packages/All/gmp-6.2.1.pkg  
> > [CA72_ZFS] Installing gmp-6.2.1...
> > the most recent version of gmp-6.2.1 is already installed
> > ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found  
> > *** Error code 1
> > 
> > 
> > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> > 
> > 
> > checking for GNU 
> > M4 that supports accurate traces... configure: error: no acceptable m4 coul
> d be found in
> > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
> > GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> > 
> > 
> > ld: error: /usr/local/lib/libblkid.a: unknown file type
> > 
> > 
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> > 
> > 
>
> Hello 
>
> whar is the recent status of fixing/mitigate this desatrous bug? Especially f
> or those with the
> new option enabled on ZFS pools. Any advice?
>
> In an act of precausion (or call it panic) I shutdown several servers to prev
> ent irreversible
> damages to databases and data storages. We face on one host with /usr/ports r
> esiding on ZFS
> always errors on the same files created while staging (using portmaster, leav
> es the system
> with noninstalled software, i.e. www/apache24 in our case). Deleting the work
>  folder doesn't
> seem to change anything, even when starting a scrubbing of the entire pool (R
> AIDZ1 pool) -
> cause unknown, why it affects always the same files to be corrupted. Same wit
> h deve/ruby-gems.
>
> Poudriere has been shutdown for the time being to avoid further issues. 
>
> Are there any advies to proceed apart from conserving the boxes via shutdown?
>
> Thank you ;-)
> oh
>
>
>
> -- 
> O. Hartmann

With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded 
blocks. #14739" patch I didn't have any issues, except for email messages 
with corruption in my sent directory, nowhere else. I'm still investigating 
the email messages issue. IMO one is generally safe to run poudriere on the 
latest ZFS with the additional patch.

My tests of the additional patch concluded that it resolved my last 
problems, except for the sent email problem I'm still investigating. I'm 
sure there's a simple explanation for it, i.e. the email thread was 
corrupted by the EXDEV regression which cannot be fixed by anything, even 
reverting to the previous ZFS -- the data in those files will remain 
damaged regardless.

I cannot speak to the others who have had poudriere and other issues. I 
never had any problems with poudriere on top of the new ZFS.

Re: OpenZFS recently (was aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!])

[void]

On Sat, Apr 15, 2023 at 09:56:34AM +0100, Graham Perrin wrote:


Is the recent situation unusual enough to warrant an entry in UPDATING?



yeah I'd say so.

Also does this affect 13-stable and the recent 13.2-RELEASE or 
just -current?


--

Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75

[FreeBSD User]

Am Thu, 13 Apr 2023 22:18:04 -0700
Mark Millard  schrieb:

> On Apr 13, 2023, at 21:44, Charlie Li  wrote:
> 
> > Mark Millard wrote:  
> >> FYI: in my original report for a context that has never had
> >> block_cloning enabled, I reported BOTH missing files and
> >> file content corruption in the poudriere-devel bulk build
> >> testing. This predates:
> >> https://people.freebsd.org/~pjd/patches/brt_revert.patch
> >> but had the changes from:
> >> https://github.com/openzfs/zfs/pull/14739/files
> >> The files were missing from packages installed to be used
> >> during a port's build. No other types of examples of missing
> >> files happened. (But only 11 ports failed.)  
> > I also don't have block_cloning enabled. "Missing files" prior to 
> > brt_revert may actually
> > be present, but as the corruption also messes with the file(1) signature, 
> > some tools like
> > ldconfig report them as missing.  
> 
> For reference, the specific messages that were not explicit
> null-byte complaints were (some shown with a little context):
> 
> 
> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - not found
> ===>   Installing existing package /packages/All/libxml2-2.10.3_1.pkg  
> [CA72_ZFS] Installing libxml2-2.10.3_1...
> [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done
> ===>   py39-lxml-4.9.2 depends on shared library: libxml2.so - found
> (/usr/local/lib/libxml2.so) . . .
> [CA72_ZFS] Extracting libxslt-1.1.37: .. done
> ===>   py39-lxml-4.9.2 depends on shared library: libxslt.so - found
> (/usr/local/lib/libxslt.so) ===>   Returning to build of py39-lxml-4.9.2  
> . . .
> ===>  Configuring for py39-lxml-4.9.2  
> Building lxml version 4.9.2.
> Building with Cython 0.29.33.
> Error: Please make sure the libxml2 and libxslt development packages are 
> installed.
> 
> 
> [CA72_ZFS] Extracting libunistring-1.1: .. done
> ===>   libidn2-2.3.4 depends on shared library: libunistring.so - not found  
> 
> 
> [CA72_ZFS] Extracting gmp-6.2.1: .. done
> ===>   mpfr-4.2.0,1 depends on shared library: libgmp.so - not found  
> 
> 
> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found
> ===>   Installing existing package /packages/All/gmp-6.2.1.pkg  
> [CA72_ZFS] Installing gmp-6.2.1...
> the most recent version of gmp-6.2.1 is already installed
> ===>   nettle-3.8.1 depends on shared library: libgmp.so - not found  
> *** Error code 1
> 
> 
> autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4
> 
> 
> checking for GNU 
> M4 that supports accurate traces... configure: error: no acceptable m4 could 
> be found in
> $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> 
> 
> ld: error: /usr/local/lib/libblkid.a: unknown file type
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

Hello 

whar is the recent status of fixing/mitigate this desatrous bug? Especially for 
those with the
new option enabled on ZFS pools. Any advice?

In an act of precausion (or call it panic) I shutdown several servers to 
prevent irreversible
damages to databases and data storages. We face on one host with /usr/ports 
residing on ZFS
always errors on the same files created while staging (using portmaster, leaves 
the system
with noninstalled software, i.e. www/apache24 in our case). Deleting the work 
folder doesn't
seem to change anything, even when starting a scrubbing of the entire pool 
(RAIDZ1 pool) -
cause unknown, why it affects always the same files to be corrupted. Same with 
deve/ruby-gems.

Poudriere has been shutdown for the time being to avoid further issues. 

Are there any advies to proceed apart from conserving the boxes via shutdown?

Thank you ;-)
oh



-- 
O. Hartmann

OpenZFS recently (was aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 [zfs corruptions without block_cloning involved!])

[Graham Perrin]

On 14/04/2023 11:58, Mark Millard wrote:

… zfs after the import corrupts data even without block_cloning having ever 
been in use, even as the code currently is. More problems are to be found and 
fixed yet, despite the several fixes now in place.

See for example …



Is the recent situation unusual enough to warrant an entry in UPDATING?



OpenPGP_signature
Description: OpenPGP digital signature