Archive-Team
/
zfs
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 103 Wiki Activity

Don't allocate from new metaslabs 

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes #15307
Closes #15308
This commit is contained in:
Paul Dagnelie 2023-09-28 14:08:52 -07:00 committed by GitHub
parent ec994486b1
commit 5551dcd762
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
module/zfs/metaslab.c
View File

@ -3250,6 +3250,15 @@ metaslab_segment_weight(metaslab_t *msp)
static boolean_t static boolean_t
metaslab_should_allocate(metaslab_t *msp, uint64_t asize, boolean_t try_hard) 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 * 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 * the fast check. If it's not, the ms_max_size is a lower bound (once