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

Add comment on metaslab_class_throttle_reserve() locking 

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Issue #12314
Closes #12419
This commit is contained in:
Alexander Motin 2021-07-26 19:30:20 -04:00 committed by GitHub
parent bdd2bfd02c
commit dd3bda39cf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
module/zfs/metaslab.c
View File

@ -5617,6 +5617,13 @@ metaslab_class_throttle_reserve(metaslab_class_t *mc, int slots, int allocator,
if (GANG_ALLOCATION(flags) || (flags & METASLAB_MUST_RESERVE) || if (GANG_ALLOCATION(flags) || (flags & METASLAB_MUST_RESERVE) ||
zfs_refcount_count(&mca->mca_alloc_slots) + slots <= max) { zfs_refcount_count(&mca->mca_alloc_slots) + slots <= max) {
/* /*
* The potential race between _count() and _add() is covered
* by the allocator lock in most cases, or irrelevant due to
* GANG_ALLOCATION() or METASLAB_MUST_RESERVE set in others.
* But even if we assume some other non-existing scenario, the
* worst that can happen is few more I/Os get to allocation
* earlier, that is not a problem.
*
* We reserve the slots individually so that we can unreserve * We reserve the slots individually so that we can unreserve
* them individually when an I/O completes. * them individually when an I/O completes.
*/ */