Description of problem:
As of now command like 'lvs' obtain reported value via multiple status commands.
Even though recently there have been few upstream commits to reduce number of
ioctl dm status calls - it's still not ideal.
We have number of 'LV' field, then lots of 'segment' properties and there is unclear boundary.
We target logic to treat showing of 'segment' fields for 'single-segment-type-LV' as LV properties - so values of properties like 'transactionId' for thin volume should not be invoking 'segment' output.
But we also have couple internal function code that are running 'complex' code and solving multi-segment operation on a single place - and number of such places grows in lvm2 code base - we need to split this function into 'segment' methods so whenever we add a new 'segment' we do not need to hunt&seek all multi-seg locations - since omitting upgrade often leads to 'well hidden' troubles later.
So we seek for a 'display' method which shows values either in 'segment' or in 'LV' mode - when i.e. mirror can aggregate percentage value from all mirror segments or show a single segment value.
Other important moment is to clearly define what is being display in fields like 'data%' which were originally designed to show 'similar values' from different types which could not have appear at once on a single LV. However with more advances we know allow more complex LV stacking and we are in position where displayed field may present a value for more then a single LV (e.g. snapshot origin may either show 'snapshot-merging' or 'origin's' values.)
Version-Release number of selected component (if applicable):
Steps to Reproduce: