Bug 1335048

Summary:	[RFE] Simplify reporting of cache statistic
Product:	[Community] LVM and device-mapper	Reporter:	Zdenek Kabelac <zkabelac>
Component:	lvm2	Assignee:	LVM Team <lvm-team>
lvm2 sub component:	Displaying and Reporting	QA Contact:	cluster-qe <cluster-qe>
Status:	NEW ---	Docs Contact:
Severity:	unspecified
Priority:	medium	CC:	agk, heinzm, jbrassow, msnitzer, prajnoha, teigland, zkabelac
Version:	2.02.152	Flags:	agk: lvm-technical-solution? rule-engine: lvm-test-coverage?
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Zdenek Kabelac 2016-05-11 08:47:45 UTC

Description of problem:

ATM the cache statistic (dm target status) data are quite uncomfortable to use.
User has to enter long keywords:

cache_used_blocks,cache_dirty_blocks,cache_read_hits,cache_read_misses,
cache_write_hits,cache_write_misses

also 'lvs' output then uses very wide columns:

LV   VG             Attr       LSize  Pool    Origin Data%  Meta%  Move Log Cpy%Sync Convert CacheDirtyBlocks CacheReadHits    CacheReadMisses  CacheWriteHits   CacheWriteMisses
LV1  vg             Cwi-a-C--- 14.00m [cpool]        5.56   0.61            87.50                          14               80              148              910             1760

There are number of options to consider:

- Using 'shorter' heading.
- Use 2 line heading with 2 lines output per LV
- Implement aggregated option (like 'pv_all'?)
- See what profile can do - but it has its limits well
- ... 

Version-Release number of selected component (if applicable):
2.02.152

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
User 'friendlier' visualization of cache usage.


Additional info:

Comment 1 David Teigland 2016-05-11 15:06:11 UTC

Another option is to display stats using a different tool, without the single-line restriction.  'lvs' is mainly about listing LVs.  (It can still be *possible* to display stats with lvs, but it doesn't need to be the only or optimal way.)

Comment 2 Peter Rajnoha 2016-05-12 10:03:12 UTC

(In reply to Zdenek Kabelac from comment #0)
> There are number of options to consider:
> 
> - Using 'shorter' heading.
> - Use 2 line heading with 2 lines output per LV
> - Implement aggregated option (like 'pv_all'?)
> - See what profile can do - but it has its limits well

I think one of the limits you mean that profile initialization causes toolcontext refresh. As an optimization here, we could mark settings which do not require refresh (via flag in config_setting.h) and if the profile contains only these settings, we can omit the refresh. Surely, all those settings which set the list of fields to display do not really need the toolcontext refresh...

Comment 3 Zdenek Kabelac 2016-05-12 14:53:18 UTC

(In reply to David Teigland from comment #1)
> Another option is to display stats using a different tool, without the
> single-line restriction.  'lvs' is mainly about listing LVs.  (It can still
> be *possible* to display stats with lvs, but it doesn't need to be the only
> or optimal way.)

There are available  'dmsetup status' based scripts with 'stats' output - so this BZ should focus on command 'integrated' VG lock protected access.

Comment 4 David Teigland 2016-05-12 15:42:11 UTC

Yes, I think we should focus on lvdisplay, and not have 'lvs' print statistics by default.

Comment 5 Peter Rajnoha 2016-05-12 15:53:20 UTC

(In reply to David Teigland from comment #4)
> Yes, I think we should focus on lvdisplay, and not have 'lvs' print
> statistics by default.

...lvdisplay doesn't go through reports and as such doens't support -S|--select just like lvs does. And with these statistical info, it may be quite useful to do selections.