Yes they did, and I made certain to credit you by name when we covered the closing of this bug in the most recent 2.5 Admins episode, 2.5 Admins 248: NASty Pi – 2.5 Admins.
I had a sneaking suspicion that my Dec 22 2024 mention that the one major difference that might exist between syncoid and other replication efforts was the way syncoid manually walks the dataset tree rather than using native recursion might have led you to your Dec 26 2024 reproducer script, and I did mention that on the episode as well, but I gave you the well-deserved lion’s share of the credit because you are correct, nothing was really getting done until you successfully produced a reproducer that functioned in a reasonable amount of time.
Paul Dagnelie and others from Allan Jude’s team at Klara did, from my understanding, a ton of the actual in-kernel dev work, along with upstream devs including but not limited to George Amanakis, but initial, non kernel developer work done by our community here at Practical ZFS was crucial to getting this resolved, and I’m damned proud of us for it.
While we’re giving out credit, Richard Yao also created a cool automated check to discover similar bugs which might exist elsewhere in the codebase or be accidentally introduced in the future; and Klara clients fastmail.com, rsync.net, and nber.org donated some of their support budget with Klara to fund those efforts.
As I said on episode 248, this bug really took a community to fix, not just a few elite kernel developers, and that makes this a really shining Cinderella story for open source software in general, not to mention the actual specific annoying as hell and long-term bug that’s finally resolved.
(plus a little friendly ribbing for the btrfs devs)
(Also, I don’t have to listen to any more shit from disgruntled btrfs devs who enjoyed scapegoating OpenZFS with that bug anymore. I’m typing that with a friendly grin, mind you, btrfs devs… and I’m rooting for y’all, I seriously am. But I’m still typing it, grin and rooting or not.
)