zfs test mdb_001_pos can fail

Review Request #2541 — Created April 27, 2020 and submitted May 1, 2020, 11:05 p.m.

Information
Owner:	jbk
Repository:	illumos-gate
Branch:
Bugs:	12028
Depends On:
Reviewers
Groups:	general
People:

Description

Testing Done

Ran test

Issues

0
0
2
0
All Issues: 2

Description	From	Last Updated
I don't know enough about the implementation to know what to expect, but this command gives me results I don't ...	kkantor	April 28, 2020, 8:59 p.m.
Does ksh provide the ability to use a 'for'-style iteration so we don't have to do the indexing+incrementing dance? That ...	kkantor	April 28, 2020, 8:59 p.m.

Ship it!

```
Ship It!
```

Looks good! I'm looking forward to having this fixed. I just had a couple questions related to my own ignorance.

usr/src/test/zfs-tests/tests/functional/mdb/mdb_001_pos.ksh (Diff revision 1)

Show all issues

I don't know enough about the implementation to know what to expect, but this command gives me results I don't understand on a few of the systems I tested it on:

> metaslab_alloc_trace_cache::metaslab_trace
  MSID    DVA    ASIZE   ALLOCATOR      WEIGHT             RESULT               VDEV
     - 1869828096        0           0       0.03E     ? (1574881664)

However, when I use a command more similar to what was there before I get normal looking results:

> ::walk spa | ::walk metaslab | ::head -1 | ::metaslab_trace
  MSID    DVA    ASIZE   ALLOCATOR      WEIGHT             RESULT               VDEV
   458      0        0    e4e43840           0                 20

jbk April 28, 2020, 3:57 p.m.

Looking at it closer, I'm not sure either one is correct -- I think what might have been intended is *metaslab_alloc_trace_cache::walk kmem | ::metaslab_trace -- metaslab_alloc_trace_cache is a kmem_cache_t, and appears to be used to allocate metaslab_alloc_trace_t instances -- the ::walk metaslab walker will yield the addresses of metaslab_ts.

kkantor April 28, 2020, 9:22 p.m.

I was still a little confused about this dcmd usage so jbk and I synced up. It sounds like we need metaslab tracing turned on to really exercise the ::metaslab_trace dcmd. It would be nice if there were a comment in the script about this (and any other no-op test cases in this list) or if we turned on that feature while we run this test. The fact that the test works (even with some no-ops) and doesn't fail is good enough for a +1 from me though.

usr/src/test/zfs-tests/tests/functional/mdb/mdb_001_pos.ksh (Diff revision 1)

Show all issues

Does ksh provide the ability to use a 'for'-style iteration so we don't have to do the indexing+incrementing dance? That might make this loop a tad more readable if we could use that style.

jbk April 28, 2020, 3:57 p.m.
```
Yeah..
```

Diff:

Revision 2 (+9 -30)

Show changes

usr/src/test/zfs-tests/tests/functional/mdb/mdb_001_pos.ksh

Ship it!

```
Ship It!
```

Ship it!

```
Ship It!
```

You have a pending review.

Review Board 3.0.18

zfs test mdb_001_pos can fail

Diff:

Status: Closed (submitted)