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
