Hacker News Reader

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.

View on HN

Don't forget how `zfs send | zfs receive` could cause both pools to be corrupted, reported in

- https://github.com/openzfs/zfs/issues/15140 : supposed to be from flushing largepages

- https://github.com/openzfs/zfs/issues/15275 fixed by https://github.com/openzfs/zfs/issues/15464 : linked to block cloning

Block cloning is a large suspect.

2nd 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.

Coming 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.

Reply on news.ycombinator.com