-
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
Rework error handling in zpool_trim() #10372
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Codecov Report
@@ Coverage Diff @@
## master #10372 +/- ##
==========================================
+ Coverage 79.52% 79.62% +0.10%
==========================================
Files 391 391
Lines 123590 123608 +18
==========================================
+ Hits 98288 98427 +139
+ Misses 25302 25181 -121
Continue to review full report at Codecov.
|
When a manual trim is run against an entire pool, errors about particular devices which don't support trim are suppressed. This changes zpool_trim() in libzfs so that it doesn't return an error when the only errors are suppressed ones. An exception is made when none of the devices support trim, in which case an error is reported and a non-zero status is returned. This also fixes how the --wait flag works in the presence of suppressed errors. In particular, suppressed errors no longer cause zpool_trim() to skip the wait. Signed-off-by: John Gallagher <john.gallagher@delphix.com>
When a manual trim is run against an entire pool, errors about particular devices which don't support trim are suppressed. This changes zpool_trim() in libzfs so that it doesn't return an error when the only errors are suppressed ones. An exception is made when none of the devices support trim, in which case an error is reported and a non-zero status is returned. This also fixes how the --wait flag works in the presence of suppressed errors. In particular, suppressed errors no longer cause zpool_trim() to skip the wait. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: John Gallagher <john.gallagher@delphix.com> Closes openzfs#10263 Closes openzfs#10372 (cherry picked from commit 50ff632)
When a manual trim is run against an entire pool, errors about particular devices which don't support trim are suppressed. This changes zpool_trim() in libzfs so that it doesn't return an error when the only errors are suppressed ones. An exception is made when none of the devices support trim, in which case an error is reported and a non-zero status is returned. This also fixes how the --wait flag works in the presence of suppressed errors. In particular, suppressed errors no longer cause zpool_trim() to skip the wait. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: John Gallagher <john.gallagher@delphix.com> Closes openzfs#10263 Closes openzfs#10372
Motivation and Context
When a manual trim is run against an entire pool, errors about particular devices which don't support trim are suppressed. However, a non-zero status is returned. Moreover, if a wait was requested it is skipped, as if there had been a fatal error.
Description
This changes
zpool_trim()
inlibzfs
so that it doesn't return an error when the only errors are suppressed ones. An exception is made when none of the devices support trim, in which case an error is reported and a non-zero status is returned.This also fixes how the --wait flag works in the presence of suppressed errors. In particular, suppressed errors no longer cause
zpool_trim()
to skip the wait.I did some refactoring that I felt helped make the updated error-handling logic simpler. It also fixes a small memory leak, and a assertion failure that can happen in certain error paths, both related to the
errlist
nvlist constructed bylzc_trim
.How Has This Been Tested?
Ran
zpool trim
against a pool with devices which all support trim, against a pool with a mixture of devices that support trim and devices that don't, and against a pool with only devices that don't support trim. I checked that an error was reported in the third scenario, but not the first two.I repeated the same tests, except specifying the vdevs explicitly instead of just trimming the whole pool. In this case, an error was reported in both of the last two scenarios.
In all cases, I check that a non-zero exit status was returned if and only if and only if an error was reported.
I also checked that in all of the scenarios above, if the wait flag was specified, the wait was performed unless an error was reported.
Types of changes
Checklist:
Signed-off-by
.