Skip to content
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

Closed
mabod opened this issue May 11, 2021 · 7 comments
Closed

corrupted pool with 2.1.0-rc5 #12025

mabod opened this issue May 11, 2021 · 7 comments
Labels
Status: Triage Needed New issue which needs to be triaged Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@mabod
Copy link

mabod commented May 11, 2021

System information

Type Version/Name
Distribution Name EndeavourOS
Distribution Version
Linux Kernel 5.12.2 (zen)
Architecture x86 (AMD)
ZFS Version 2.1.0-rc5
SPL Version 2.1.0-rc5

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:

  pool: zstore
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: scrub repaired 0B in 07:35:40 with 0 errors on Thu Apr  1 07:35:41 2021
config:

	NAME                       STATE     READ WRITE CKSUM
	zstore                     ONLINE       0     0     0
	  mirror-0                 ONLINE       0     0     0
	    WD40EFRX-WCC7K6XALFKX  ONLINE       0     0     0
	    WD40EFRX-WCC7K2YAJA69  ONLINE       0     0     0
	  mirror-1                 ONLINE       0     0     0
	    WD40EFRX-WCC7K6YX6SAA  ONLINE       0     0     0
	    WD40EFRX-WCC7K4JKN36U  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        zstore/data/BACKUP/rakete_home:<0x0>

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:

6# zfs mount zstore/data/BACKUP/rakete_home
cannot mount 'zstore/data/BACKUP/rakete_home': Input/output error

How should I approach this now?

@mabod mabod added Status: Triage Needed New issue which needs to be triaged Type: Defect Incorrect behavior (e.g. crash, hang) labels May 11, 2021
@AttilaFueloep
Copy link
Contributor

Most likely this is #11294, so your pool should be fine. I'd just wait for #11300 to land or revert d1d4769.

@mabod
Copy link
Author

mabod commented May 11, 2021

ok. Or can I just go back to 2.0.4? Will that clear the error?

@mabod
Copy link
Author

mabod commented May 11, 2021

I downgraded to 2.0.4 and the error is still there. :-(
Does that mean a scrub is needed to fix this?

PS
With zfs 2.0.4 the dataset is mounted it least.

@AttilaFueloep
Copy link
Contributor

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.

@mabod
Copy link
Author

mabod commented May 11, 2021

ok. thanks. May be this question is off topic, but why isnt it possible to do selective / partial scrubs for specific datasets. e.g.
zpool scrub mypool/mydataset
This would help dramatically to fix an issue like this.

@AttilaFueloep
Copy link
Contributor

Dunno, I think in theory it should be possible to scrub only blocks referenced by a certain dataset.

@mabod
Copy link
Author

mabod commented May 12, 2021

One scrub was enough for me to remove the error message. Thanks. I will close this issue.

@mabod mabod closed this as completed May 12, 2021
behlendorf added a commit to behlendorf/zfs that referenced this issue May 12, 2021
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
behlendorf added a commit to behlendorf/zfs that referenced this issue May 12, 2021
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
behlendorf added a commit that referenced this issue May 13, 2021
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
rincebrain pushed a commit to rincebrain/zfs that referenced this issue May 17, 2021
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
rincebrain pushed a commit to rincebrain/zfs that referenced this issue May 17, 2021
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
behlendorf added a commit to behlendorf/zfs that referenced this issue May 28, 2021
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
sempervictus pushed a commit to sempervictus/zfs that referenced this issue May 31, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Triage Needed New issue which needs to be triaged Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

No branches or pull requests

2 participants