Originally posted by woddy
View Post
Announcement
Collapse
No announcement yet.
OpenZFS 2.2.1 Released Due To A Block Cloning Bug Causing Data Corruption
Collapse
X
-
-
Originally posted by curfew View PostThis statement is nonsensical. It was found because it ate someone's data. If it didn't, well, then it wouldn't even be a real bug because it doesn't affect anyone.
You should've finished off with "hopefully it was found and fixed before too many people unknowingly updated to the broken version."
define real bug please.
- Likes 2
Leave a comment:
-
Currently there are at least two fundamental issues in OpenZFS, one may also affect the older, stable 2.1.x branch.
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 ...
I build and regularly test ZFS from the master branch. A few days go I built and tested the commit specified in the headline of this issue, deploying it to three machines. On two of them (the ones ...
2.2.1 doesn't fix that.
- Likes 2
Leave a comment:
-
Originally posted by waxhead View Post
Yes it is, very much so. And this comes from an btrfs evangelist. But it has bugs like all software that has updates. The important thing is that it was found....
You should've finished off with "hopefully it was found and fixed before too many people unknowingly updated to the broken version."
Leave a comment:
-
Originally posted by Rallos Zek View PostNothing new! ZFS always had a history of eating data and being unstable.
Of the 6 or so times I have tried using btrfs, only one did not end in an unmountable filesystem with btrfs recover getting me about ~40% of the data back. The one that wasn't a total loss wasn't a win either, It was a 4 disk stripe of mirrors, and I just got lucky when btrfs kicked the "right" two drives out leaving the fs mountable.
Rebuilt the array on OpenZFS and it has been rock solid since
- Likes 2
Leave a comment:
-
Originally posted by skeevy420 View PostIMHO, this does highlight that OpenZFS's internal and beta/RC testing might not be as robust as it could or should be.
- Likes 2
Leave a comment:
-
Not that surprising that a bug could eventually slip through, especially in an area that has been heavily modified in the latest version.
Disappointing that it wasn't caught by ztest though. Hopefully they expand the testsuite coverage to catch this bug and any others like it.
- Likes 1
Leave a comment:
-
Yeah, I already noticed that block cloning is not quite "ready". I ran into a bug just a few days ago when I copied two small text files from one dataset to another. The file appeared to copy, but when I tried opening the file it caused the system to hang to the point where I had to manually reset it. After rebooting, I tried opening the file again, and that caused the system to hang again. I soon noticed that "zpool status" was reporting a problem with those two files so I deleted them and ran a full drive scrub. Everything seems fine now.
Leave a comment:
-
Originally posted by skeevy420 View Post
You can't set it to disabled. It's irreversible. Enabled means able to be used but inactive. Active means in use. As long as it stays "enabled" you're not using it. I think that's confusing, too.
What you'll have to do is something like setting "cp --reflink=never" globally to make sure that the default "--reflink=auto" doesn't accidentally use reflinks which will trigger your pool to go into an "active" state. Assuming you ever go into an active state, you can delete the copied-with-reflinks files and it should switch from "active" to "enabled".
IMHO, disabled, inactive, and active would be better descriptions since enabled can be mistaken to mean active and both inactive and active describe the current state of enable so they both imply a feature to be enabled.
Leave a comment:
-
Originally posted by muncrief View PostDoes anyone know how to disable block cloning?
I upgraded to 2.2.1 but block cloning is still enabled, even though none of my pools are using it. The output of "zpool get all | grep block_cloning" shows "feature@block_cloning enabled", not active, and from what I've found that means it's not being used. But I can't find a way to set it to disabled.
What you'll have to do is something like setting "cp --reflink=never" globally to make sure that the default "--reflink=auto" doesn't accidentally use reflinks which will trigger your pool to go into an "active" state. Assuming you ever go into an active state, you can delete the copied-with-reflinks files and it should switch from "active" to "enabled".
IMHO, disabled, inactive, and active would be better descriptions since enabled can be mistaken to mean active and both inactive and active describe the current state of enable so they both imply a feature to be enabled.
- Likes 2
Leave a comment:
Leave a comment: