Bug 192097 - zpool status -x reports wrong information
Summary: zpool status -x reports wrong information
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-24 17:46 UTC by dustinwenz
Modified: 2022-09-21 12:49 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dustinwenz 2014-07-24 17:46:56 UTC
If a user has a pool created in FreeBSD 9.2 or earlier, it's likely that the ashift value is off. After upgrading to FreeBSD 10, zpool status correctly reports "block size: 512B configured, 4096B native".

The problem is that when "zpool status -x" is run, it also reports the block size message. The documentation for -x states: "Only display status for pools that are exhibiting errors or are otherwise unavailable". While an ashift of 9 may not be ideal, it's a perfectly functional configuration and not an error. The new behavior is wrong because it presents many lines of messages, even when there are no degraded pools or data integrity errors.

I personally find this annoying because I routinely check hundreds of pools for failing disks using the -x option, and it's easy to miss these errors when many pools have ashift=9. I'm already aware that the pools need to rebuilt to avoid that message, which is a process that will take years to complete. In the meantime, I still need to handle disk errors without being bombarded with redundant block size messages.
Comment 1 Allan Jude freebsd_committer freebsd_triage 2018-10-04 01:10:01 UTC
It is a configuration error however. Using 512b for 4k devices will cause performance degradation because of the read-modify-write that the hardware will have to do for every 512b write.

I don't think it makes sense to locally modify the behaviour of ZFS in this instance.

Hopefully we will eventually get the "Time Variable Geometry" feature for ZFS that will allow all future allocations to be made 4k aligned, even in the face of pools created on older versions of FreeBSD where we didn't have quirks in place on some disks that lie about their sector size.

Video and Slides about the feature. "Oh Shift!"

https://www.youtube.com/watch?v=_-QAnKtIbGc

https://drive.google.com/file/d/0B5fzqkw_-diCZFVTZlpua3hjNWs/view?usp=sharing
Comment 2 Erik Inge Bolsø 2022-09-21 12:49:42 UTC
I'd argue that performance problems like this should be excluded from "zpool status -x" output, like old disk formats with features not enabled. Two sides of the same coin in my view.