Cy Schubert wrote:
Hmm, interesting. I'm experiencing no such panics nor corruption since the commit.Reading a previous email of yours from today block_cloning is not enabled. Is it possible that before the regression was fixed, while it was wreaking havoc in your zpool, that your zpool became irreversibly corrupted resulting in panics, even with the fixed code?
This is probably now the case.
Fails to mount with error 45 on a boot environment only a few commits before the import.One way, probably the best way, to test would be to revert back to the commit prior to the import. If you still experience panics and corruption, your zpool is damaged.
At the moment we don't know if the code is still broken or if it has been fixed but residual damage is still causing creeping rot and panics. I don't know if zpool scrub can fix this -- reading one comment on FreeBSD-current, zpool scrub fails to complete.
It doesn't. All scrubs on my end complete fully with nothing to repair.
Going to try recreating the pool on current tip, making sure that block_cloning is disabled.I'm not convinced, yet, that the problem code has not been fixed. We don't know if the panics are a result of corruption as a result of the regression. Would it be best if we reverted the seven commits to main? I don't know. I could argue it either way. My problems, on four machines, have been fixed by the subsequent commits. We don't know if there are other regressions or if the current problems are due to corruption caused writes prior to patches addressing the regression. Maybe reverting the seven commits and taking a watch for further fallout approach, whether the panics and problems persist post revert. If the problems persist post revert we know for sure the regression has caused some permanent corruption. This is a radical option. IMO, I'm torn whether a revert would be the best approach or not. It has its merits but significant limitations too.
-- Charlie Li …nope, still don't have an exit line.
OpenPGP_signature
Description: OpenPGP digital signature
