[Pkg-zfsonlinux-devel] Bug#1104724: Bug#1104724: Bug#1104724: zfs-dkms: Kernel panic and kernel blocks with zfs 2.3.2-1 and linux 6.12.25-1

[Stefan Bellon]

On Wed, 07 May, Shengqi Chen wrote:

> Since the problem originates from one single directory (~/.config),

I'm not sure this is actually true. It's just that I noticed that
at least ~/.config/fish/* is affected as I am unable to open a "fish"
shell as that user.

On the other hand, the stack traces I provided in my bug report also
show other processes besides "fish" to be affected (e.g. txg_sync,
z_wr_iss, ...), so I am not sure how "local" the issue is.

> try to copy all its content to another location without copy-on-write,
> e.g.:
> 
> mv ~/.config ~/.config_old
> cp -ar --reflink=never ~/.config_old ~/.config
> # after check
> rm -rf ~/.config_old
>
> You can create a tar and untar to replace the cp.

That's actually an interesting idea. So I could definitely - with
little effort - do that for ~/.config/fish/* and then verify whether a
"fish" shell successfully opens afterwards and whether at least that
stack trace for "fish" does not appear any more.

> If you encountered any errors, you can try zdb -r further.

I think I would require some pointers to what to do with that, in order
not to make things worse.

> This could “force” zfs to produce new blocks for these objects.
> The corrupted blkptr will get removed if it is not referenced (but
> be aware that there could be snapshots referring to it).

For my understanding: the kernel panic and hangs I am experiencing are
all when accessing data in the active dataset. So, if I would get
that clean, I could still encounter the issue when accessing the same
affected files via a snapshot, but at least the active dataset would
be clean and if the (automatic) snapshots get dropped over time, this
would cure it for the whole pool?

And another question: When booting into the kernel 6.12.25 with ZFS
2.3.2, would it make sense to run "zpool scrub" from there, or could
this make things worse?

And final question for now: Would it make sense to open an issue at
OpenZFS on GitHub, or at least open a discussion topic there? I still
think, this is pretty unexpected for a mere ZFS user to end in a
situation where the system breaks if you upgrade but works "flawlessly"
on the older patch-level version.

Greetings,
Stefan