Actions
Bug #4978
closedztest fails in get_metaslab_refcount()
Start date:
2014-07-09
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
External Bug:
Description
George Wilson:
Running zloop on my latest bits I hit a failure here: > $c get_metaslab_refcount+0x4c(8521180, 4, 8047a58, 8055737, 8520cc0, fefc3330) get_metaslab_refcount+0x8f(851f500, 8073700, 8047a78, 0, 0, 0) verify_spacemap_refcounts+0x4c(8541000, 8047b14, 0, 8523fa0, 0, ffffffff) dump_zpool+0x1f0(8541000, 805ed33, 2, ffffffff) main+0x6fb(805e5ba, feffb0a4, 8047b64, 805555f, 0, 8047b70) _start+0x83(5, 8047c4c, 8047c98, 8047c9b, 8047cb2, 8047cb6) 8521180::print vdev_t vdev_ms[] Hmm, the vddv_ms array is NULL. This is causing this to fail: nt get_metaslab_refcount(vdev_t *vd) { int refcount = 0; if (vd->vdev_top == vd) { for (int m = 0; m < vd->vdev_ms_count; m++) { space_map_t *sm = vd->vdev_ms[m]->ms_sm; <snip> The root cause is that this vdev is being removed and vdev_ms has already been cleared out. We should check for removing vdevs when making this check.
Updated by Electric Monk almost 9 years ago
- Status changed from New to Closed
git commit 2e4c998613148111f2fc5371085331ffb39122ff
commit 2e4c998613148111f2fc5371085331ffb39122ff Author: George Wilson <george.wilson@delphix.com> Date: 2014-07-19T20:19:25.000Z 4976 zfs should only avoid writing to a failing non-redundant top-level vdev 4977 mdb error in ::spa_space from space_cb() if a metaslab's ms_sm is NULL 4978 ztest fails in get_metaslab_refcount() 4979 extend free space histogram to device and pool 4980 metaslabs should have a fragmentation metric 4981 remove fragmented ops vector from block allocator 4982 space_map object should proactively upgrade when feature is enabled 4983 need to collect metaslab information via mdb 4984 device selection should use fragmentation metric Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Adam Leventhal <adam.leventhal@delphix.com> Reviewed by: Christopher Siden <christopher.siden@delphix.com> Approved by: Garrett D'Amore <garrett@damore.org>
Actions