-
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
zpool clear hang #3082
Milestone
Comments
This is related to #2878. |
Turns out
|
It looks like it must be down |
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Feb 26, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. The needed information is already cached in memory. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Feb 26, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. The needed information is already cached in memory. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Feb 27, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. The needed information is already cached in memory. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Mar 2, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. We need to ensure the list of features enabled on the pool stays resident in memory. There already exists an nvlist for this purpose called ZPOOL_CONFIG_ENABLED_FEAT in spa->spa_load_info. The features_for_write features aren't added to the list, however, in the final import phase. This patch updates spa_load_impl() so the features_for_read and features_for_write features are both added to ZPOOL_CONFIG_ENABLED_FEAT in each import phase. The full list of pool features and their initial reference counts are now available for use in spa_add_feature_stats(). In spa_add_feature_stats() we iterate over the spa_feature_table[] rather than the ZAP objects read from disk. We operate on ZPOOL_CONFIG_ENABLED_FEAT in-place and refresh the reference counts for the supported features from the values cached in the spa_t. This is sufficient for 'zpool get all' to display correct values for the unsupported@ and feature@ properties. For the unsupported features, if the reference count is 0 is shows 'inactive' otherwise it shows 'read-only'. In either case, the unsupported reference counts could not have changed after import, so it is safe to rely on the initial values. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Mar 3, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. We need to ensure the list of features enabled on the pool stays resident in memory. There already exists an nvlist for this purpose called ZPOOL_CONFIG_ENABLED_FEAT in spa->spa_load_info. The features_for_write features aren't added to the list, however, in the final import phase. This patch updates spa_load_impl() so the features_for_read and features_for_write features are both added to ZPOOL_CONFIG_ENABLED_FEAT in each import phase. The full list of pool features and their initial reference counts are now available for use in spa_add_feature_stats(). In spa_add_feature_stats() we iterate over the spa_feature_table[] rather than the ZAP objects read from disk. We operate on ZPOOL_CONFIG_ENABLED_FEAT in-place and refresh the reference counts for the supported features from the values cached in the spa_t. This is sufficient for 'zpool get all' to display correct values for the unsupported@ and feature@ properties. For the unsupported features, if the reference count is 0 is shows 'inactive' otherwise it shows 'read-only'. In either case, the unsupported reference counts could not have changed after import, so it is safe to rely on the initial values. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
behlendorf
pushed a commit
to behlendorf/zfs
that referenced
this issue
Mar 4, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. We need to ensure the list of features enabled on the pool stays resident in memory. There already exists an nvlist for this purpose called ZPOOL_CONFIG_ENABLED_FEAT in spa->spa_load_info. The features_for_write features aren't added to the list, however, in the final import phase. This patch updates spa_load_impl() so the features_for_read and features_for_write features are both added to ZPOOL_CONFIG_ENABLED_FEAT in each import phase. The full list of pool features and their initial reference counts are now available for use in spa_add_feature_stats(). In spa_add_feature_stats() we iterate over the spa_feature_table[] rather than the ZAP objects read from disk. We operate on ZPOOL_CONFIG_ENABLED_FEAT in-place and refresh the reference counts for the supported features from the values cached in the spa_t. This is sufficient for 'zpool get all' to display correct values for the unsupported@ and feature@ properties. For the unsupported features, if the reference count is 0 is shows 'inactive' otherwise it shows 'read-only'. In either case, the unsupported reference counts could not have changed after import, so it is safe to rely on the initial values. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Mar 5, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. To keep the feature stats resident in memory, we hang a cached nvlist off of the spa. It is built up from disk the first time spa_add_feature_stats() is called, and refreshed thereafter using the cached feature reference counts. spa_add_feature_stats() gets called at pool import time so we can be sure the cached nvlist will be available if the pool is later suspended. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Mar 5, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. To keep the feature stats resident in memory, we hang a cached nvlist off of the spa. It is built up from disk the first time spa_add_feature_stats() is called, and refreshed thereafter using the cached feature reference counts. spa_add_feature_stats() gets called at pool import time so we can be sure the cached nvlist will be available if the pool is later suspended. Fixes openzfs#3082 Signed-off-by: Ned Bass <[email protected]>
DeHackEd
pushed a commit
to DeHackEd/zfs
that referenced
this issue
Apr 4, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. To keep the feature stats resident in memory, we hang a cached nvlist off of the spa. It is built up from disk the first time spa_add_feature_stats() is called, and refreshed thereafter using the cached feature reference counts. spa_add_feature_stats() gets called at pool import time so we can be sure the cached nvlist will be available if the pool is later suspended. Signed-off-by: Ned Bass <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#3082
DeHackEd
pushed a commit
to DeHackEd/zfs
that referenced
this issue
Apr 5, 2015
Avoid issuing I/O to the pool when retrieving feature flags information. Trying to read the ZAPs from disk means that zpool clear would hang if the pool is suspended and recovery would require a reboot. To keep the feature stats resident in memory, we hang a cached nvlist off of the spa. It is built up from disk the first time spa_add_feature_stats() is called, and refreshed thereafter using the cached feature reference counts. spa_add_feature_stats() gets called at pool import time so we can be sure the cached nvlist will be available if the pool is later suspended. Signed-off-by: Ned Bass <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#3082
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
zpool clear
command may hang when attempting to resume a pool. This is a regression which was introduced on all the platforms when feature flags were added. What's happening here is that thespa_get_stats()
function always attempts to fetch the feature stats. When these buffers aren't cached in the ARC it results in an IO to a suspended pool which blocks. These IO needs to be eliminated either by always caching the feature stats or perhaps just by skipping them when the pool is known to be suspended.The text was updated successfully, but these errors were encountered: