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

[Shawn Webb]

On Thu, Apr 13, 2023 at 06:48:14PM -0400, Charlie Li wrote:
> Shawn Webb wrote:
> > Does the ZFS project have some sort of automated testing to catch
> > data-gobbling, pool killing bugs? It seems like this would have been
> > caught with some CI/CD stress testing automation scripts.
> > 
> I can't speak about how the OpenZFS project does things, but this particular
> corruption does not have any deterministic characteristics both pre- and
> post-condition, so would be hard to automate testing.

My approach would be to have a policy by which any new feature
scheduled to land in the main branch must also not show any
regressions when running `poudriere bulk -ac`. Such a policy could be
enforced via server-side git commit hook. One problem, though, is that
implementing that policy isn't just a matter of code, but also
infrastructure, so there's a tangible monetary cost.

I should mention that I appreciate the selfless hard work of those
involved in the FreeBSD and OpenZFS projects. I hope for continued
incremental improvements.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

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

[Mark Millard]

From: Dima Panov  wrote on
Date: Fri, 14 Apr 2023 06:55:29 UTC :

> On 14.04.2023 01:13, Dimitry Andric wrote:
> > On 13 Apr 2023, at 23:42, Dima Panov  wrote:
> >> Somethings changed in main branch between Mar, 28 and Apr, 8 which causes 
> >> permanent build error for lang/gcc1[012] on aarch64 (exactly VMWare 
> >> container on M1Pro mac)
> >>
> >> during RTL pass: sched1
> >> gimple-match.cc: In function 'bool gimple_nop_atomic_bit_test_and_p(tree, 
> >> tree_node**, tree_node* (*)(tree))':
> >> gimple-match.cc:39215:1: internal compiler error: Segmentation fault
> >> 39215 | }
> >> | ^
> >> mmap: Invalid argument
> >> Please submit a full bug report, with preprocessed source (by using 
> >> -freport-bug).
> >> See  for instructions.
> >> gmake[4]: *** [Makefile:1145: gimple-match.o] Error 1
> >> gmake[4]: *** Waiting for unfinished jobs
> >> rm gcc.pod gfortran.pod
> > 
> > Are you running this build on zfs? There are apparently a bunch of
> > filesystem corruption problems which have surfaced due to recent openzfs
> > imports.
> > 
> 
> 
> Yup, pure zfs install.
> Discussion refers to block_cloning but it disabled on my pool

It is not true that it is limited to block_cloning. 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 (much of the reporting is on both freebsd-current
and dev-commits-src-main but some is only in one place or the
other):

https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014397.html

https://lists.freebsd.org/archives/freebsd-current/2023-April/003446.html

https://lists.freebsd.org/archives/freebsd-current/2023-April/003449.html
https://lists.freebsd.org/archives/freebsd-current/2023-April/003459.html

https://lists.freebsd.org/archives/freebsd-current/2023-April/003460.html

> DATA feature@block_cloning disabled local

You will still get corruptions but they will not be as
fundamental to problems restoring the pool to a good state.
[There is work in progress to try to have block_cloning
being enabled recoverable but effectively disabled other
than cleaning itself up. But this will not fix the other
cause(s) of corruption, which are still being worked on
as well.]

===
Mark Millard
marklmi at yahoo.com

Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8

[Dima Panov]

Moin-moin!

On 14.04.2023 01:13, Dimitry Andric wrote:

On 13 Apr 2023, at 23:42, Dima Panov  wrote:

Somethings changed in main branch between Mar, 28 and Apr, 8 which causes 
permanent build error for lang/gcc1[012] on aarch64 (exactly VMWare container 
on M1Pro mac)

during RTL pass: sched1
gimple-match.cc: In function 'bool gimple_nop_atomic_bit_test_and_p(tree, 
tree_node**, tree_node* (*)(tree))':
gimple-match.cc:39215:1: internal compiler error: Segmentation fault
39215 | }
  | ^
mmap: Invalid argument
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
See  for instructions.
gmake[4]: *** [Makefile:1145: gimple-match.o] Error 1
gmake[4]: *** Waiting for unfinished jobs
rm gcc.pod gfortran.pod


Are you running this build on zfs? There are apparently a bunch of
filesystem corruption problems which have surfaced due to recent openzfs
imports.




Yup, pure zfs install.
Discussion refers to block_cloning but it disabled on my pool

DATA  feature@block_cloning  disabled   local



--
Sincerely,
Dima (flu...@freebsd.org, https://t.me/FluffyBSD)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team


OpenPGP_signature
Description: OpenPGP digital signature