--json option does not respect -o option #17873
Description
Describe the feature you would like to see added to OpenZFS
For the zpool and zfs utilities, the --json option is great.
But it needs at least the ability to tell it not to include the source column in the output.
There are plenty of times (I would strongly surmise most of them) when the user does not want ALL of the output.
In particular, when getting values of properties, one often really doesn't care where they came from - just what they are. And for some properties, source isn't even a relevant concept no matter what, such as type, used, or any other intrinsic dataset-specific properties.
But, the --json output always includes value and source for every property, completely ignoring the -o option.
Proposal is to respect the -o option for JSON output.
How will this feature improve OpenZFS?
Significant reduction in memory footprint of the zfs and zpool utilities and whatever consumes their output, when using the --json option, as well as consistency in the command line syntax and behavior.
Additional context
I'm sure the justification is pretty self-explanatory, but here's an illustration just for sake of argument:
The source property adds a very non-negligible amount of text to the output, whether you want it or not.
I ran some simple comparisons that anyone should be able to replicate on pretty much any pool.
The average length in bytes of a bunch of zfs get -t all -r --json commands I ran on several pools on production systems, for various specific collections of properties and also for all, is more than double the size of the same JSON with just the source properties removed from it. And that is including a bunch of user properties that have long string values skewing the results toward a smaller ratio, too (ie, on a pool without those properties, it should be even worse).
The JSON of a full dump of all properties 9or even more than just a small handful of properties) is several dozen megabytes for even fairly small pools, when snapshots are included, unless you're keeping a REALLY small number of them around. It makes a massive difference in the memory footprint of the utilities themselves and of whatever is consuming their output (which is ostensibly not a human if opting for JSON). And the memory cost of even just the text itself is paid by the system a minimum of at least twice every time, just from the copy from stdout to wherever it's going. Not to mention it takes time and memory to build all that output from the nvlists. And of course it goes without saying that the formatted version of the JSON blows up even worse, since source is itself a complex object.
Other thoughts
Most important is at least being able to exclude source. May as well do that by using the option that already exists (-o)
A nice-to-have would be an option to get more compact output in general, such as omitting defaults, only including source for inherited or received properties, or even an ultra-terse mode to just get the zfsprops in a simplified "propname": "propValue" form, perhaps even by default, unless the source has been asked for (or the other way around is cool too, of course).