From 5551dcd762d12265c4640cbce5ad4f1605c825ef Mon Sep 17 00:00:00 2001 From: Paul Dagnelie Date: Thu, 28 Sep 2023 14:08:52 -0700 Subject: [PATCH] Don't allocate from new metaslabs Reviewed-by: Brian Behlendorf Signed-off-by: Paul Dagnelie Closes #15307 Closes #15308 --- module/zfs/metaslab.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/module/zfs/metaslab.c b/module/zfs/metaslab.c index dd4ff77e6f..8635403d6a 100644 --- a/module/zfs/metaslab.c +++ b/module/zfs/metaslab.c @@ -3250,6 +3250,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