Don't allocate from new metaslabs

Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Paul Dagnelie <[email protected]> Closes openzfs#15307 Closes openzfs#15308
behlendorf · Sep 28, 2023 · e84b162 · e84b162
1 parent 74ee84b
commit e84b162
Showing 1 changed file with 9 additions and 0 deletions.
diff --git a/module/zfs/metaslab.c b/module/zfs/metaslab.c
@@ -3208,6 +3208,15 @@ metaslab_segment_weight(metaslab_t *msp)
 static boolean_t
 metaslab_should_allocate(metaslab_t *msp, uint64_t asize, boolean_t try_hard)
 {
+	/*
+	 * This case will usually but not always get caught by the checks below;
+	 * metaslabs can be loaded by various means, including the trim and
+	 * initialize code. Once that happens, without this check they are
+	 * allocatable even before they finish their first txg sync.
+	 */
+	if (unlikely(msp->ms_new))
+		return (B_FALSE);
+
 	/*
 	 * If the metaslab is loaded, ms_max_size is definitive and we can use
 	 * the fast check. If it's not, the ms_max_size is a lower bound (once