Skip Navigation
Heads up for a data corruption bug in ZFS, few versions affected, might have started at 2.1.x, but many reports on 2.2.x
  • It appears the issue arises more when a ZFS file system is being used in a primary nature; e.g., reading and writing to it directly as a part of some active operation. Are you using it as a backup/archive, or as a primary partition where your OS and applications are writing to it directly? If it's the former, it would seem you're much more unlikely to encounter the issue.

  • Heads up for a data corruption bug in ZFS, few versions affected, might have started at 2.1.x, but many reports on 2.2.x
  • Thank you. I've been keeping an eye on the thread to see if any consensus emerges regarding any better understanding of how the corruption manifests itself. It appears there is a possibility that a portion could be zeroed out and then new data written over it, giving the impression that all is well, but where the file is obviously still corrupt. It seems the best method is to have a list of checksums from known good files, but that obviously requires previous action that may or may not have occurred (obviously, most people never anticipated this and thus have no such list).

  • Heads up for a data corruption bug in ZFS, few versions affected, might have started at 2.1.x, but many reports on 2.2.x
  • Thank you. Upon reading further, the state of block cloning seems to be the major variable as to whether any corruption has occurred. However, there appears to remain a non-zero chance that such corruption could occur regardless of block cloning and dates back to 2.1.4/2.1.5 which were released in March/June of 2022.

  • InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)SL
    SlyFox125 @alien.top
    BOT
    Posts 0
    Comments 4