Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Jul 2014 17:46:56 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 192097] New: zpool status -x reports wrong information
Message-ID:  <bug-192097-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192097

            Bug ID: 192097
           Summary: zpool status -x reports wrong information
           Product: Base System
           Version: 10.0-STABLE
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: dustinwenz@ebureau.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-192097-8>