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

zfault.sh fails hard read error raid0 #124

Closed
ryantig opened this issue Feb 25, 2011 · 3 comments
Closed

zfault.sh fails hard read error raid0 #124

ryantig opened this issue Feb 25, 2011 · 3 comments

Comments

@ryantig
Copy link

ryantig commented Feb 25, 2011

/usr/src/zfs-0.6.0-rc1$ sudo /usr/libexec/zfs/zfault.sh -cv
Destroying /dev/md0
/dev/md1
/dev/md2
/dev/md3
Creating /dev/loop0 using /tmp/zpool-lo.NgPs9GyN
Creating /dev/md0 using /dev/loop0
Destroying /dev/md0
Destroying /dev/loop0
raid0 raid10 raidz raidz2 raidz3
1 soft write error Pass Pass Pass Pass Pass
2 hard write error Pass Pass Pass Pass Pass
3 all write errors Pass Pass Pass Pass Pass
4 soft read error Pass Pass Pass Pass Pass
5 hard read error Fail (33)

@behlendorf
Copy link
Contributor

So most of the zfault.sh bugs I've seen have been in the test suite. Injecting exactly the right fault at the right place and time is surprisingly difficult. In this case error code 33 indicates we injected an error which should have caused a hard read error, but zpool claims there was no error. That could mean a lot of thing you might try running zfault.sh again and see if it's transient or reproducable.

@ryantig
Copy link
Author

ryantig commented Feb 25, 2011

I tried 3 runs and it had error 33 each time before I submitted. Then just now I ran again.... And naturally, it didn't reproduce this time. ack.
/usr/src/zfs-0.6.0-rc1$ sudo /usr/libexec/zfs/zfault.sh -cv
[sudo] password for ryan:
Destroying /dev/md0
/dev/md1
/dev/md2
/dev/md3
Creating /dev/loop0 using /tmp/zpool-lo.62BI9Sul
Creating /dev/md0 using /dev/loop0
Destroying /dev/md0
Destroying /dev/loop0
raid0 raid10 raidz raidz2 raidz3
1 soft write error Pass Pass Pass Pass Pass
2 hard write error Pass Pass Pass Pass Pass
3 all write errors Pass Pass Pass Pass Pass
4 soft read error Pass Pass Pass Pass Pass
5 hard read error Pass Pass Pass Pass Pass
6 fixable read error Pass Pass Pass Pass Pass
7 silent data corruption Pass Pass Pass Pass Pass
8 soft write timeout Pass Pass Pass Pass Pass
9 hard write timeout Skip Pass Pass Pass Pass

@behlendorf
Copy link
Contributor

Still, it sounds like a flaw in the test case I'll need to run down.

dajhorn referenced this issue in zfsonlinux/pkg-zfs Sep 7, 2012
torvalds/linux@1dce27c introduced
__clear_close_on_exec() as a replacement for FD_CLR. Further commits
appear to have removed FD_CLR from the Linux source tree.  This
causes the following failure:

  error: implicit declaration of function '__FD_CLR'
  [-Werror=implicit-function-declaration]

To correct this we update the code to use the current
__clear_close_on_exec() interface for readability.  Then we introduce
an autotools check to determine if __clear_close_on_exec() is available.
If it isn't then we define some compatibility logic which used the older
FD_CLR() interface.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #124
@bud4 bud4 mentioned this issue Feb 12, 2018
richardelling pushed a commit to richardelling/zfs that referenced this issue Oct 15, 2018
sdimitro pushed a commit to sdimitro/zfs that referenced this issue Feb 14, 2022
Grabbing and releasing the state lock for each of the blocks that we
need to free is very expensive.  By grabbing the lock once for each
MergeMessage::Progress, performance improves by ~100x, and processing
these frees is no longer a performance-limiting factor.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants