Project

General

Profile

Bug #9738

9112 broke third block copy allocations within one metaslab group

Added by Alexander Motin about 1 year ago. Updated 12 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2018-08-16
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

metaslab_group_alloc_normal() sets tertiary variable for some allocation requests to push those allocations to different metaslab by calling for them find_valid_metaslab() instead of reusing cached secondary metaslab. The problem appears later when activation_weight is still set to METASLAB_WEIGHT_SECONDARY, and metaslab_activate_allocator() can not differentiate those tertiary allocations from secondary, and as result fails, since the allocator already has one secondary metaslab.

In practice I see under heavy write load, when, probably due to write throttling, all 3 copies of some blocks are regularly trying to allocate from the same metaslab group. It causes multiple metaslab_activate() errors, causing load of more metaslabs then necessary, that, combined with caused preloader misses, makes pool to hang regularly for several seconds waiting for metaslab load on demand.

History

#2

Updated by Electric Monk 12 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit b86e7e3f0e50748bb5bb5cc91632d72ff17f08dd

commit  b86e7e3f0e50748bb5bb5cc91632d72ff17f08dd
Author: Alexander Motin <mav@FreeBSD.org>
Date:   2018-10-04T14:32:20.000Z

    9738 9112 broke third block copy allocations within one metaslab group
    Reviewed by: Paul Dagnelie <pcd@delphix.com>
    Reviewed by: George Wilson <george.wilson@delphix.com>
    Approved by: Robert Mustacchi <rm@joyent.com>

Also available in: Atom PDF