Date: Sat, 28 Oct 2023 09:40:23 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@FreeBSD.org> Cc: Colin Percival <cperciva@tarsnap.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: 15-aarch64-RPI-snap Message-ID: <183A9CD0-42DB-4A0C-982D-FC6D3980163A@yahoo.com> In-Reply-To: <3B40F89C-7E5E-427F-A7A1-2D37CCC06A6F@yahoo.com> References: <0100018b6a9d257c-b35e4157-ba97-4aa7-988c-aba797c6d2ca-000000@email.amazonses.com> <ACBCBC83-DD61-4E0A-89DC-9DDD1B71B8DE@freebsd.org> <13B64416-4334-4070-8588-71F7D938350B@yahoo.com> <3B40F89C-7E5E-427F-A7A1-2D37CCC06A6F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 27, 2023, at 23:00, Mark Millard <marklmi@yahoo.com> wrote:
> On Oct 27, 2023, at 22:24, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On Oct 27, 2023, at 21:34, Glen Barber <gjb@FreeBSD.org> wrote:
>>=20
>>>>> . . .
>>>>> =
^
>>>>> ./offset.inc:16:19: error: null character ignored =
[-Werror,-Wnull-character]
>>>>> =
<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U=
+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0=
000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+000=
0><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>=
<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U=
+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0=
000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+000=
0><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>=
<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U=
+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0=
000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+000=
0><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000>=
<U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U+0000><U=
+0000><U+0000><U+0000><U+00
>>>>> 00><U+0000>#undef _SA
>>>>> =
=
^
>>=20
>> Are the above from a ZFS file system? UFS? Something else?
>>=20
>> Back in 2021-Nov (15..21) I had problems where ZFS was leading
>> to blocks of such on aarch64, not specifically RPi*'s, various
>> files but not the same ones from test to test. When I updated
>> past some zfs updates on the 23rd the problem stopped.
>>=20
>> I also have notes from 2022-Mar (19..22) about replicating
>> another example problem someone was having with files ending
>> up with such blocks of bytes but the testing was on the
>> ThreadRipper 1950X. (The replication showed that ccache did
>> not need to be involved since I've never used it.) Again
>> ZFS was part of the environment that got the replication.
>> Mark Johnson fixed sys/contrib/openzfs/module/zfs/dnode.c
>> during this and my ability to replicate the issue then
>> stopped when I tested the patch.
>>=20
>> Which ever file system it is that holds the bad bytes, some
>> attempted testing for repeatability of the problem could
>> be of interest, some of that being on aarch64 but not on
>> RPi*'s, some of it not on aarch64 at all. But it might take
>> information about the context to know better what/how to
>> test. That could include information about both the host and
>> the jail OS versions if such is involved.
>=20
> Those last notes are likely too generic, in that normally
> official buildworld buildkernel activity is done on amd64
> for all target platforms (last I knew). (Not that running
> such builds on other platforms would be a bad problem-scope
> isolation test.)
>=20
> Any notes that help delimit what sort of test context
> would be a reasonable partial replication of the original
> context could prove useful.
>=20
>> . . .
If the file system is ZFS, I'll note that main [so: 15] already has
a zpool feature that is not part of openzfs-2.2 and so not part of
releng/14.0 or stable/14 . So what zpool features are enabled could
be relevant to problems that only happen in main and might need to
be involved in efforts to replicate the problem.
But I've not evaluated if redaction_list_spill would be likely to
possibly be involved for the specific type of file corruptions.
=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?183A9CD0-42DB-4A0C-982D-FC6D3980163A>