Don't activate metaslabs with weight 0

We return ENOSPC in metaslab_activate if the metaslab has weight 0,
to avoid activating a metaslab with no space available.  For sanity
checking, we also assert that there is no free space in the range
tree in that case.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed by: Matt Ahrens <matt@delphix.com>
Reviewed by: Serapheim Dimitropoulos <serapheim.dimitro@delphix.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes #8968
This commit is contained in:
Paul Dagnelie 2019-07-05 16:45:20 -07:00 committed by Tony Hutter
parent f3f46b0e45
commit 66c8b2f65a

View File

@ -2485,6 +2485,18 @@ metaslab_activate(metaslab_t *msp, int allocator, uint64_t activation_weight)
return (0); return (0);
} }
/*
* If the metaslab has literally 0 space, it will have weight 0. In
* that case, don't bother activating it. This can happen if the
* metaslab had space during find_valid_metaslab, but another thread
* loaded it and used all that space while we were waiting to grab the
* lock.
*/
if (msp->ms_weight == 0) {
ASSERT0(range_tree_space(msp->ms_allocatable));
return (SET_ERROR(ENOSPC));
}
if ((error = metaslab_activate_allocator(msp->ms_group, msp, if ((error = metaslab_activate_allocator(msp->ms_group, msp,
allocator, activation_weight)) != 0) { allocator, activation_weight)) != 0) {
return (error); return (error);
@ -3735,8 +3747,8 @@ metaslab_group_alloc_normal(metaslab_group_t *mg, zio_alloc_list_t *zal,
* worse metaslab (we waited for that metaslab to be loaded * worse metaslab (we waited for that metaslab to be loaded
* after all). * after all).
* *
* If the activation failed due to an I/O error we skip to * If the activation failed due to an I/O error or ENOSPC we
* the next metaslab. * skip to the next metaslab.
*/ */
boolean_t activated; boolean_t activated;
if (activation_error == 0) { if (activation_error == 0) {