3 ms·
Reporter of #15526 here. I've still only ever seen this corruption in files being built, which seems to be a situation that the race can be won repeatably by so
by terinjokes 3y ago
Reporter of #15526 here. I've still only ever seen this corruption in files being built, which seems to be a situation that the race can be won repeatably by some packages. I reviewed all my user data and I've found no corruption to it, but my workloads don't involve block clones.
- thulle 3y ago2nd in the bug here. I actually have some blockcloned data, f.e. steam uses it for all proton installs, but no issues other than the go build.
- thulle 3y agoComing back home and checking 2.2.1 out zfs instantly started spewing write & checksum errors due to #15533. Both this and #15526 seem to have underlying issues from <2.2 that are just more easily triggered now. First one also confirmed on FreeBSD now. Holding off on 2.2 seems recommended, and if you're keeping critical data on OpenZFS it might be a good idea to give the issues a glance. The 2nd one might have the same underlying solution as an issue that has given me system freezes when closing in on ~90% pool usage using 2.1 on top of LUKS.
- csdvrx 3y agoDon't forget how `zfs send | zfs receive` could cause both pools to be corrupted, reported in - https://github.com/openzfs/zfs/issues/15140 https://github.com/openzfs/zfs/issues/15140 : supposed to be from flushing largepages - https://github.com/openzfs/zfs/issues/15275 https://github.com/openzfs/zfs/issues/15275 fixed by https://github.com/openzfs/zfs/issues/15464 https://github.com/openzfs/zfs/issues/15464 : linked to block cloning Block cloning is a large suspect.