Bug 1465974 - Improve warnings about available space in a thin pool
Improve warnings about available space in a thin pool
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: David Teigland
Depends On:
  Show dependency treegraph
Reported: 2017-06-28 10:55 EDT by David Teigland
Modified: 2018-04-02 17:51 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Teigland 2017-06-28 10:55:36 EDT
Description of problem:

(Copying here from an old lvm etherpad page.)

Warnings related to thin pools.

Make these configurable by % level, where 0% disables warnings.
With these warnings in place, remove the warning about overprovisioning when thin LVs are created.

$ lvs dd
WARNING: thin pool "pool" is 75% full.
  LV    VG Attr       LSize   Pool 
  lv1   dd rwi---r---   1.00g      
  lv2   dd -wi-------   1.00g      
  lvol0 dd -wi-------   1.00g      
  lvol1 dd -wi-------   1.00g      
  pool  dd twi---tz--   1.00g      
  thin1 dd Vwi---tz-- 100.00g pool 
$ lvcreate -n thin2 -V100G --thinpool dd/pool
WARNING: thin pool "pool" is 75% full.
  Logical volume "thin2" created.

Examples of other kinds of warnings we could print when the %full level reaches the configured value.

$ lvs dd
WARNING: thin pool "pool" is 75% full.
WARNING: thin pool "pool" will be extended at 90% full.
WARNING: thin pool "test" is 81% full.
WARNING: thin pool "test" will require manual extension.
WARNING: VG "dd" has insufficient space for the next thin pool extensions.
WARNING: VG "dd" will require 20G of space for the next thin pool extensions, but 4GB is available.

Define soft_warn_percent setting for each pool.  At this percent full, commands using the VG will begin reporting warnings.  The soft_warn_percent would be some level below the point where the pool is actually extended.  By setting soft_warn_percent=0, the warnings are disabled.

In the example above, "pool" and "test" have soft_warn_percent=75, so when each reaches 75% full, commands begin printing:
- the current percent full of pools over soft_warn_percent, e.g. "... is 75% full."
- the percent full at which a pool will be autoextended, e.g. "... will be extended at 90% full."
- if autoextend is not enabled for the pool, it prints that it will require manual extension.
- if the VG does not have sufficient free space for the next extension of each thin pool, it prints that warning.


(I don't think reporting in terms of overprovisioning is very good; it's hard to understand what it means or if it's important.)

Another idea is to report the amount of overprovisioning in a VG.

$ lvs dd
WARNING: thin pool "pool" is 150% overprovisioned.

The actual %over that triggers the warning could be configurable for each pool, e.g. overprovisioning_warn_percent, with 0% meaning to disable the warning.
This message would require that we specifically define the meaning of overprovisioned percent.

Percents can get confusing, so it may be better to just report actual amounts of space that are overprovisioned, e.g.

$ lvs dd
WARNING: thin pool "pool" is 400GB overprovisioned.

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

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 2 David Teigland 2017-06-28 11:10:37 EDT
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:
Comment 3 Alasdair Kergon 2017-07-06 12:35:15 EDT
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.

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