Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fragmentation should display as '-' if spacemap_histogram=disabled #2664

Closed
ilovezfs opened this issue Sep 5, 2014 · 1 comment
Closed

Comments

@ilovezfs
Copy link
Contributor

ilovezfs commented Sep 5, 2014

Currently, we are printing '18446744073709551615' instead of '-' when the fragmentation property is not available (i.e., whenever the feature flag spacemap_histogram is not enabled).

ilovezfs added a commit to ilovezfs/openzfs_fork that referenced this issue Sep 5, 2014
When com.delphix:spacemap_histogram is disabled, the value of
fragmentation was printing as 18446744073709551615 (UINT64_MAX),
when it should print as '-'.

The issue was caused by a small mistake during the merge of
"4980 metaslabs should have a fragmentation metric."

upstream:
illumos/illumos-gate@2e4c998
ZOL:
openzfs@f3a7f66

The problem is in zpool_get_prop_literal, where the handling of the
pool property ZPOOL_PROP_FRAGMENTATION was added to wrong the
section. In particular, ZPOOL_PROP_FRAGMENTATION should not be in
the section where zpool_get_state(zhp) == POOL_STATE_UNAVAIL, but
lower down after it's already been determined that the pool is in
fact available, which is where upstream illumos correctly has had
it.

Thanks to lundman for helping to track down this bug.

Issue openzfs#2664
@ilovezfs
Copy link
Contributor Author

ilovezfs commented Sep 5, 2014

OK, opened pull request with the fix:
#2665

ilovezfs added a commit to openzfsonosx/zfs that referenced this issue Sep 5, 2014
When com.delphix:spacemap_histogram is disabled, the value of
fragmentation was printing as 18446744073709551615 (UINT64_MAX),
when it should print as '-'.

The issue was caused by a small mistake during the merge of
"4980 metaslabs should have a fragmentation metric."

upstream:
illumos/illumos-gate@2e4c998
ZOL:
openzfs/zfs@f3a7f66

The problem is in zpool_get_prop_literal, where the handling of the
pool property ZPOOL_PROP_FRAGMENTATION was added to wrong the
section. In particular, ZPOOL_PROP_FRAGMENTATION should not be in
the section where zpool_get_state(zhp) == POOL_STATE_UNAVAIL, but
lower down after it's already been determined that the pool is in
fact available, which is where upstream illumos correctly has had
it.

Thanks to lundman for helping to track down this bug.

Issue openzfs/zfs#2664
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant