The motivation for designing configurable and useful warnings like those above was to remove this warning when you create a thin LV:

"WARNING: Sum of all thin volume sizes (%s) exceeds the size of thin pool%s%s%s (%s)!",

Better reporting about thin pool usage in general would make that warning unnecessary.

A user provided good feedback about this same issue:
https://www.redhat.com/archives/linux-lvm/2016-April/msg00032.html

Well step 1 is to define the fields that the warnings will use as their basic input as reporting fields.

So can we propose some new lvs -o fields that would provide the information required in the right form?

Step 2 is then to model the selection criteria for the warnings using -S.

Then that might provide us with a general framework:
  hook name (inserted at a given source location)
  -S condition to match
  warning message to issue

We then need to consider how to split the configurability between config file and VG metadata.  In the example given, is the warning threshold part of the VG metadata and/or part of lvm.conf?

So we probably need to work though more examples and see what sort of framework falls out.

Proposal seems to be  useful for a user with very few resources as there can be made a quick 'human mapping' between  WARNING line and actual problematic device.

However as the number of LVs in system grows up - such output may become confusing even more as the number of WARNING lines will tend to grow-up.

So it does seem we may need few things -  as comment 3  stated - it should have been accessible as some column field.

I also do believe we should start to use colorized output - as majority of today's admins simply do use colorized terminals (we are not in 1980 with black&white vt100 anymore :)) in IMHO it greatly enhances readability of i.e. journals...

I'd probably welcome even a new specific command designed just for reporting problems  (i.e.  lvproblems - or whatever better names comes)  - giving an individual verbose messaging about issues.

Supporting  -S with lvs  probably achieves same goal - but other tools seems to provide individual commands as well and it may be simpler - but just brainstorming....

For proposed new variables like overprovisioning_warn_percent,  soft_warn_percent,...   
There could some concept of  'PG-rating' being 0..100 so admins sets his experience and lvm2 will translate warning to some verbosity (I can imagine this very nicely with colorized output - where different LVs turns  white->orange->red at different occasions...)

We have several 'similar' issues:

We have old snapshots going out of space.
We have raid, mirrors, thin-pools, caches requiring fixing

So the choice is - adding many specific individual settings for every single instance (users do get lot in them very quickly) or think about some common pattern between them and control it via 'admin experience'.

There is various degree of information needed to provide qualified users response.

(I think that output related to overprovision/percent which I included at the end of the original description is a bad idea.)


For now, I think we should just improve the warning message to be clearer and more useful.

When autoextend is disabled or monitoring is not used, then print:

  WARNING: thin pool "pool" is 75% full and will require manual extension.

When autoextend is enabled but there's not enough space in the VG to do it, then print:

  WARNING: thin pool "pool" is 75% full and the VG has insufficent space to autoextend.

Allow the 75% level to be set by the user in lvm.conf according to how early they want to be warned.

There is another warning that we might want to print about all thin pools collectively if there's not enough space to autoextend all of them:

WARNING: VG "test" will require 10G to autoextend all thin pools, only 5G is available.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.