20:39:51 <bahamat> xmerlin: We have been able to reproduce it with the reproducer script, but it's much less frequent than it seems like other systems are encountering. The most recent release from last week includes the fix.
20:59:29 <xmerlin> bahamat as I can see you have integrate the patch without mutex but the patch in illumos and openzfs use mutex ...why?
21:36:28 <bahamat> xmerlin: We imported it early. Was there an additional issue found that necessitated the mutex, or is it just extra precaution?
21:37:41 <bahamat> Let me check with Dan...we might respin the release.
21:51:23 <bahamat> Ok, so the mutex was put into openzfs for a completely unrelated issue, over two years ago where lseek(2) would fail, seemingly at random.
21:52:24 <bahamat> But it doesn't seem to be related to the data corruption issue.
21:53:09 <bahamat> So we're not respinning the release, but it will be in our next release (and in the current dev build, assuming it finished).
21:54:02 <bahamat> And yeah, that build has finished.
21:55:19 <bahamat> That image is master-20231204T135840Z
22:05:50 <danmcd> Worst case xmerlin is that the window of 16087 gets only much smaller without the mutex.  With the mutex it should be eliminated.
22:06:16 <danmcd> I ran 100 runs of the brute-force parallel reproducer on the release-build and it didn't trigger at all.
22:06:20 <danmcd> (it == the bug)