OpenZFS 2.2.1 Released Due To A Block Cloning Bug Causing Data Corruption
- Thread starter gea
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
hmm.......
github.com
some copied files are corrupted (chunks replaced by zeros) · Issue #15526 · openzfs/zfs
System information Type Version/Name Distribution Name Gentoo Distribution Version (rolling) Kernel Version 6.5.11 Architecture amd64 OpenZFS Version 2.2.0 Reference https://bugs.gentoo.org/917224 ...
github.com
hmmm....
www.phoronix.com
Just to add
The Solaris forks Illumos/ OpenIndiana/ OmniOS that are also Open-ZFS are not affected.
They use their own repo with "cherry picking" features from the Open-ZFS repo.
OpenZFS Is Still Battling A Data Corruption Issue - Phoronix
Just to add
The Solaris forks Illumos/ OpenIndiana/ OmniOS that are also Open-ZFS are not affected.
They use their own repo with "cherry picking" features from the Open-ZFS repo.
Last edited:
Without Block Cloning, it's really hard to hit this bug, even under "ideal" circumstances. For some context, I've been collecting some hard data on the likelihood of hitting this in different scenarios. Don't take these figures as absolutes, rather as the general order of magnitude:
Trying to hit this with tons of parallelism and with (mostly) small files, out of 700 000 copies, I am seeing about 12 errors (need to double-check which are duplicates, but 12 seems to be right). This is on a fast system with fast storage, on a fast system with potato-class storage (2.5" SMR laptop HDDs) the error rate seems to be higher. Note that this is always in a contrived scenario made to stress this particular race condition.
It's far from good, but it's also not a disaster, and the fact that it went basically completely unnoticed for so long lines up well with the data so far.
Trying to hit this with tons of parallelism and with (mostly) small files, out of 700 000 copies, I am seeing about 12 errors (need to double-check which are duplicates, but 12 seems to be right). This is on a fast system with fast storage, on a fast system with potato-class storage (2.5" SMR laptop HDDs) the error rate seems to be higher. Note that this is always in a contrived scenario made to stress this particular race condition.
It's far from good, but it's also not a disaster, and the fact that it went basically completely unnoticed for so long lines up well with the data so far.
And after that seems done, ZFS is continuing corrupting their image with things like this: PANIC: zfs: adding existent segment to range tree (offset=11f694000 size=7000) and pool is corrupted after reboot · Issue #15619 · openzfs/zfs
Recommend to keep "options zfs zfs_bclone_enabled=0" and "options zfs zfs_dmu_offset_next_sync=0" for waaay into 2024.
They need a visibly stable and a testing branch. Former which only sees bugfixes and adaptations to new kernels. Latter which shall be used for non-critical but taxing exercises like compilation, and which gets new features.
Recommend to keep "options zfs zfs_bclone_enabled=0" and "options zfs zfs_dmu_offset_next_sync=0" for waaay into 2024.
They need a visibly stable and a testing branch. Former which only sees bugfixes and adaptations to new kernels. Latter which shall be used for non-critical but taxing exercises like compilation, and which gets new features.
The bugs probably have been in ZFS forever and a day, and were exposed by block cloning. So progress is good, because it helped uncover the bugs.