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:
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.)
(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...
(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.
Yes, I think we should focus on lvdisplay, and not have 'lvs' print statistics by default.
(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.