-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
corrupted pool with 2.1.0-rc5 #12025
Comments
ok. Or can I just go back to 2.0.4? Will that clear the error? |
I downgraded to 2.0.4 and the error is still there. :-( PS |
Yes scrubbing the pool (maybe twice?) should remove the error, at least it did for me. It won't fix anything though, since there actually is no error to fix, it will just clear the remembered IO error which was there due to a code change. |
ok. thanks. May be this question is off topic, but why isnt it possible to do selective / partial scrubs for specific datasets. e.g. |
Dunno, I think in theory it should be possible to scrub only blocks referenced by a certain dataset. |
One scrub was enough for me to remove the error message. Thanks. I will close this issue. |
Commit d1d4769 takes into account the encryption key version to decide if the local_mac could be zeroed out. However, this could lead to failure mounting encrypted datasets created with intermediate versions of ZFS encyrption available in master between major releases. In order to prevent this situtation revert d1d4769 pending a more comprehensive fix which addresses the mount failure case. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11294 Issue openzfs#12025 Issue openzfs#12300
Commit d1d4769 takes into account the encryption key version to decide if the local_mac could be zeroed out. However, this could lead to failure mounting encrypted datasets created with intermediate versions of ZFS encyrption available in master between major releases. In order to prevent this situtation revert d1d4769 pending a more comprehensive fix which addresses the mount failure case. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11294 Issue openzfs#12025 Issue openzfs#12300
Commit d1d4769 takes into account the encryption key version to decide if the local_mac could be zeroed out. However, this could lead to failure mounting encrypted datasets created with intermediate versions of ZFS encryption available in master between major releases. In order to prevent this situation revert d1d4769 pending a more comprehensive fix which addresses the mount failure case. Reviewed-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #11294 Issue #12025 Issue #12300 Closes #12033
Commit d1d4769 takes into account the encryption key version to decide if the local_mac could be zeroed out. However, this could lead to failure mounting encrypted datasets created with intermediate versions of ZFS encryption available in master between major releases. In order to prevent this situation revert d1d4769 pending a more comprehensive fix which addresses the mount failure case. Reviewed-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11294 Issue openzfs#12025 Issue openzfs#12300 Closes openzfs#12033
Commit d1d4769 takes into account the encryption key version to decide if the local_mac could be zeroed out. However, this could lead to failure mounting encrypted datasets created with intermediate versions of ZFS encryption available in master between major releases. In order to prevent this situation revert d1d4769 pending a more comprehensive fix which addresses the mount failure case. Reviewed-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11294 Issue openzfs#12025 Issue openzfs#12300 Closes openzfs#12033
Commit d1d4769 takes into account the encryption key version to decide if the local_mac could be zeroed out. However, this could lead to failure mounting encrypted datasets created with intermediate versions of ZFS encryption available in master between major releases. In order to prevent this situation revert d1d4769 pending a more comprehensive fix which addresses the mount failure case. Reviewed-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11294 Issue openzfs#12025 Issue openzfs#12300 Closes openzfs#12033
Commit d1d4769 takes into account the encryption key version to decide if the local_mac could be zeroed out. However, this could lead to failure mounting encrypted datasets created with intermediate versions of ZFS encryption available in master between major releases. In order to prevent this situation revert d1d4769 pending a more comprehensive fix which addresses the mount failure case. Reviewed-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11294 Issue openzfs#12025 Issue openzfs#12300 Closes openzfs#12033
System information
Describe the problem you're observing
Today I gave 2.1.0-rc5 a try. I had 2.0.4 installed before. install with dkms was going fine, but after boot one of my pools is throwing an error:
I did not do a feature upgrade yet. Obvioulsy it is an issue with dataset
zstore/data/BACKUP/rakete_home
. It is not mounted and if I try to mount it I get:How should I approach this now?
The text was updated successfully, but these errors were encountered: