Bug 1340750 - [RFE] Improve internal reporting of LV/seg properties
Summary: [RFE] Improve internal reporting of LV/seg properties
Status: NEW
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: 2.02.152
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2016-05-30 08:49 UTC by Zdenek Kabelac
Modified: 2019-08-19 22:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
rule-engine: lvm-technical-solution?
rule-engine: lvm-test-coverage?

Attachments (Terms of Use)

Description Zdenek Kabelac 2016-05-30 08:49:56 UTC
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):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Note You need to log in before you can comment on or make changes to this bug.