since I'm personally affected by this bug[1] and this scared me somehow, I thought I'd post my research results to have a discussion about the details.
I must say I lost a bit of trust in ZFS, since it was 'sold' as rock solid unbreakable file system and now what... the sheer complexity of ZFS let's me think that this was not the only bug of this kind existing undetected in the source code.
However the communication was clear and precise, other filesystems had similar problems and I just love the feature set of zfs. So I'll give it another shot hoping that future revisions will be safe(r).
Here are my conclusions so far:
1. ZFS had a silent data corruption bug recently discussed on HN [6][7]
2. `Silent` means, you can't do anything about it without upgrading zfs (scrubs, checks, etc. don't help)
3. There is no tool to check if your data has been corrupted
4. Only once written and untouched data should be relatively safe (e.g. backups), the bug mainly affects reading data [4]
5. Setting `zfs_dmu_offset_next_sync=0` reduces probability of being affected, but no guarantee [4]
6. The bug affected any version before 2.2.2 and 2.1.14[2], but were more likely between 2.1.4 and 2.2.1 because a behaviour change in coreutils
7. The causing problem already existed much longer (since 2006?) - this is a question mark [4]
8. do a `zfs version` to see the version number
9. If you're scared (I was), please read this comment: https://news.ycombinator.com/item?id=38553342
Please let me know, if I missed something or got something wrong.
Sources:
[1]: https://www.phoronix.com/news/OpenZFS-Data-Corruption-Battle
[2]: https://www.phoronix.com/news/OpenZFS-2.2.2-Released
[3]: https://www.theregister.com/2023/12/04/two_new_versions_of_o...
[4]: https://www.reddit.com/r/zfs/comments/1826lgs/psa_its_not_bl...
[5]: https://news.ycombinator.com/item?id=38519382