OpenZFS block_cloning Bug in version 2.2.0

[LawrenceSystems]

A bug has been found in the latest version of OpenZFS according to Phoronix and other sources. I am not completely clear on how much risk there is with the latest TrueNAS Cobia but the feature does appear to be enabled on my two pools, but off for the boot pool based on running this command:

zpool get all | grep -e bclone -e block_cloning

Code:

Flashy     bcloneused                     0                              -
Flashy     bclonesaved                    0                              -
Flashy     bcloneratio                    1.00x                          -
Flashy     feature@block_cloning          enabled                        local
Rusty      bcloneused                     0                              -
Rusty      bclonesaved                    0                              -
Rusty      bcloneratio                    1.00x                          -
Rusty      feature@block_cloning          enabled                        local
boot-pool  bcloneused                     0                              -
boot-pool  bclonesaved                    0                              -
boot-pool  bcloneratio                    1.00x                          -
boot-pool  feature@block_cloning          disabled                       local

 

[Arwen]

We have a discussion over here;

Silent corruption with OpenZFS (ongoing discussion and testing)

Happy Thanksgiving, everyone! Great timing, eh? A "silent corruption" bug has been discovered recently in OpenZFS. Here is the bug report for reference. (It's a long read, and the discussion and investigation is still ongoing): https://github.com/openzfs/zfs/issues/15526 From what I can...

www.truenas.com

 

[Ericloewe]

Indeed, let's keep the discussion to one thread. The tl;dr is that it is a real issue, but very unlikely to be hit by most workloads in OpenZFS 2.1 and earlier. Block cloning makes this easily reproduceable in some workloads and the tunable set to zero really reduces the likelihood of hitting it. The bug is in hole reporting, so applications that do not deal with holes are unaffected - this seems to include at least cp from coreutils 8.x, whereas 9.x started caring (not just by default) and can hit this bug.

The general mitigation advice right now is to disable block cloning and to set the other tunable to zero/off.