]> granicus.if.org Git - zfs/commit
OpenZFS 8023 - Panic destroying a metaslab deferred range tree
authorGeorge Wilson <george.wilson@delphix.com>
Fri, 7 Apr 2017 20:50:18 +0000 (13:50 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Sun, 9 Apr 2017 23:12:35 +0000 (16:12 -0700)
commit3b7f360c9606079c518829c5bd82fe8f8a89e3c0
treee5dad1e8833519127ebee8597ea8f1ec746fbb2b
parent4c3c6b6c73e31c789a2c0ce2a70912c077f15421
OpenZFS 8023 - Panic destroying a metaslab deferred range tree

Authored by: George Wilson <george.wilson@delphix.com>
Approved by: Dan McDonald <danmcd@omniti.com>
Reviewed by: Brad Lewis <brad.lewis@delphix.com>
Reviewed by: Matt Ahrens <mahrens@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Ported-by: Giuseppe Di Natale <dinatale2@llnl.gov>
We don't want to dirty any data when we're in the final txgs of the pool
export logic. This change introduces checks to make sure that no data is
dirtied after a certain point. It also addresses the culprit of this
specific bug – the space map cannot be upgraded when we're in final
stages of pool export. If we encounter a space map that wants to be
upgraded in this phase, then we simply ignore the request as it will get
retried the next time we set the fragmentation metric on that metaslab.

OpenZFS-issue: https://www.illumos.org/issues/8023
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/2ef00f5
Closes #5991
include/sys/spa.h
module/zfs/dbuf.c
module/zfs/metaslab.c
module/zfs/spa_misc.c
module/zfs/space_map.c