Skip to content

Commit e16ffbd

Browse files
pcd1193182lundman
authored andcommitted
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
1 parent 650b01b commit e16ffbd

File tree

1 file changed

+9
-0
lines changed

1 file changed

+9
-0
lines changed

module/zfs/metaslab.c

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3250,6 +3250,15 @@ metaslab_segment_weight(metaslab_t *msp)
32503250
static boolean_t
32513251
metaslab_should_allocate(metaslab_t *msp, uint64_t asize, boolean_t try_hard)
32523252
{
3253+
/*
3254+
* This case will usually but not always get caught by the checks below;
3255+
* metaslabs can be loaded by various means, including the trim and
3256+
* initialize code. Once that happens, without this check they are
3257+
* allocatable even before they finish their first txg sync.
3258+
*/
3259+
if (unlikely(msp->ms_new))
3260+
return (B_FALSE);
3261+
32533262
/*
32543263
* If the metaslab is loaded, ms_max_size is definitive and we can use
32553264
* the fast check. If it's not, the ms_max_size is a lower bound (once

0 commit comments

Comments
 (0)