Tell HN: ZFS silent data corruption bugfix – my research results

Hey HN,

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
  7. The causing problem already existed much longer (since 2006?) - this is a question mark [4]
  8. On linux, do a `sudo modinfo zfs | grep version` to see the version number

So the only way to ENSURE your data is ok is checksumming all files on another filesystem at file level and compare or re-transfering all data from another filesystem after upgrading zfs to the latest version.

Please let me know, if I missed something or got something wrong.

Sources:

[1]: https://ift.tt/E9wqCtH

[2]: https://ift.tt/powFeMY

[3]: https://ift.tt/FZjC8Ps

[4]: https://ift.tt/4jfv3qx

[5]: https://ift.tt/F7ruTfE

[6]: https://ift.tt/ihrTF6w

[7]: https://ift.tt/W2jgvwy

from Hacker News https://ift.tt/NaZAU1D