-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Open
Labels
Bot: Not StaleOverride for the stale botOverride for the stale botType: DefectIncorrect behavior (e.g. crash, hang)Incorrect behavior (e.g. crash, hang)good first issueIndicates a good issue for first-time contributorsIndicates a good issue for first-time contributors
Description
The Issue
Running zpool status -D -p »pool« to display the dedup histogram table does not respect the -p option to print raw bytes.
Source
In looking at lib/libzutil/zutil_pool.c this issue is not surprising:
Lines 49 to 56 in 52cb284
| zfs_nicenum(dds->dds_blocks, blocks, sizeof (blocks)); | |
| zfs_nicebytes(dds->dds_lsize, lsize, sizeof (lsize)); | |
| zfs_nicebytes(dds->dds_psize, psize, sizeof (psize)); | |
| zfs_nicebytes(dds->dds_dsize, dsize, sizeof (dsize)); | |
| zfs_nicenum(dds->dds_ref_blocks, ref_blocks, sizeof (ref_blocks)); | |
| zfs_nicebytes(dds->dds_ref_lsize, ref_lsize, sizeof (ref_lsize)); | |
| zfs_nicebytes(dds->dds_ref_psize, ref_psize, sizeof (ref_psize)); | |
| zfs_nicebytes(dds->dds_ref_dsize, ref_dsize, sizeof (ref_dsize)); |
The documentation does not clarify that the -p option is ignored when displaying the table.
Solution tl;dr;
- Minimum: Clarify documentation
- Ideal: Support raw bytes output
- Most ideal: Support data output in machine parsable formats (like JSON) - see details below
Solution Ideas
At a minimum, it would be nice to update the documentation to clarify this.
Ideally:
- The
-poption would work allowing detailed data - More broadly (not limited to this one subcommand), it would be really nice if output (especially informational output, but also general admin commands) had a format option to output JSON, YAML, or some other structured easy-to-machine-parse format.
- I can't remember where, but someone wrote a great article pointing out, essentially, that it's 2021, and the fact that system utilities (of all kinds) output data in wildly different formats. This results in untold hours of writing custom parsing scripts (whether in
sh/awk/sed/tr/perl/python) to retrieve data or output for further use. (A notable example would be a script that queries data that then goes into an NMS - say Zabbix. Here, perhaps it would be monitoring free disk space or maybe other I/O stats.) - The general point was: programs (especially sysadmin programs) should have some kind of easily parsable output option to a format for which (most) languages have some kind of parsing library (e.g. JSON)
- I don't mean to suggest that the data structure of the output (e.g. field names, layout, etc.) has to be an RFC (although that would have certain advantages ...).
- Rather, the idea is that it's in a format that you can reliably load and parse without resorting to writing regex(es) and other text processing.
- I can't remember where, but someone wrote a great article pointing out, essentially, that it's 2021, and the fact that system utilities (of all kinds) output data in wildly different formats. This results in untold hours of writing custom parsing scripts (whether in
System information
It shouldn't matter since I went back and identified the problem in master... but:
openzfs on freebsd 12.2-RELEASE-p3
version: 2021020900 [latest in the freebsd pkg repo]
# zpool --version
zfs-2.0.0-rc1
zfs-kmod-v2021020900-zfs_f8ce8aed0
EDIT
I searched issues but not PRs...
Looks like JSON output is a WIP: #9973 by @ofaaland - but it doesn't seem to have much momentum
Metadata
Metadata
Assignees
Labels
Bot: Not StaleOverride for the stale botOverride for the stale botType: DefectIncorrect behavior (e.g. crash, hang)Incorrect behavior (e.g. crash, hang)good first issueIndicates a good issue for first-time contributorsIndicates a good issue for first-time contributors