[linux-lvm] Option to silence "WARNING: Sum of all thin volume sizes exceeds the size of thin pool"

[Gionatan Danti]

Hi all,
being an heavy snapshot user, I wonder if (and how) to silence such a
warning:

"WARNING: Sum of all thin volume sizes (2.00 GiB) exceeds the size of
thin pool cl_gdanti-lenovo/thinpool (1.00 GiB)!"

I fully understand the reasoning for this warning, but snapshots are
almost guaranteed to raise it. I found that by setting the
thin_pool_autoextend_threshold the warning disappears, but on some pool
I would rather like to left autoextend disabled.

So, any changes to disable the warning at least when taking snapshots?
Thanks.

[David Teigland]

Post by Gionatan Danti
Hi all,
being an heavy snapshot user, I wonder if (and how) to silence such a
"WARNING: Sum of all thin volume sizes (2.00 GiB) exceeds the size of thin
pool cl_gdanti-lenovo/thinpool (1.00 GiB)!"
I fully understand the reasoning for this warning, but snapshots are almost
guaranteed to raise it. I found that by setting the
thin_pool_autoextend_threshold the warning disappears, but on some pool I
would rather like to left autoextend disabled.
So, any changes to disable the warning at least when taking snapshots?
Thanks.

It's definitely an irritation, and I described a configurable alternative
here that has not yet been implemented:

https://bugzilla.redhat.com/show_bug.cgi?id=1465974

Is this the sort of topic where we should start making use of
https://github.com/lvmteam/lvm2/issues ?

[Gionatan Danti]

Post by David Teigland
It's definitely an irritation, and I described a configurable
alternative
https://bugzilla.redhat.com/show_bug.cgi?id=1465974
Is this the sort of topic where we should start making use of
https://github.com/lvmteam/lvm2/issues ?

Hi, the proposed solution on BZ entry seems somewhat too "invasive" to
me.
I think it generally is a good idea to warn the users about possibly
unexptected behavior (ie: full pool).

However, for the specific use-case of taking read-only snapshots,
something as simple as "--silencepoolsizewarn" flag (or similar
configuration variable) would do the trick without distrupting
legitimate warnings.

Regards.

[Zdenek Kabelac]

Post by David Teigland
It's definitely an irritation, and I described a configurable alternative
https://bugzilla.redhat.com/show_bug.cgi?id=1465974
Is this the sort of topic where we should start making use of
https://github.com/lvmteam/lvm2/issues ?

Hi, the proposed solution on BZ entry seems somewhat too "invasive" to me.
I think it generally is a good idea to warn the users about possibly
unexptected behavior (ie: full pool).
However, for the specific use-case of taking read-only snapshots, something as
simple as "--silencepoolsizewarn" flag (or similar configuration variable)
would do the trick without distrupting legitimate warnings.

We can possibly print WARNING message only with the 1st. thin LV which causes
overprovisioining of thin-pool.

As for 'read-only' snapshot - it really doesn't matter - the overprovisioned
pool can in the 'worst' case end in out-of-space condition (i.e. fully
rewritten origin)

Regards


Zdenek

[Gionatan Danti]

This post might be inappropriate. Click to display it.

[Xen]

This post might be inappropriate. Click to display it.

[matthew patton]

Post by Gionatan Danti
So, any changes to disable the warning at least when taking snapshots?
https://bugzilla.redhat.com/show_bug.cgi?id=1465974

If the warnings are not being emitted to STDERR then that needs to be fixed right off the bat.

'lvs -q blah' should squash any warnings.
'lvcreate' frankly shouldn't output anything unless invoked with '-v' anyway. So therefore '-q' should also squash warnings.

I suspect a wholesale cleanup of the way LVM does logging will suffice to fix the gratuitous and unnecessary output.

[Gionatan Danti]

Post by matthew patton
If the warnings are not being emitted to STDERR then that needs to be fixed right off the bat.

The line with WARNINGs are written on STDERR, at least con recent LVM
version.

Post by matthew patton
'lvs -q blah' should squash any warnings.
'lvcreate' frankly shouldn't output anything unless invoked with '-v' anyway. So therefore '-q' should also squash warnings.

I'm not sure this is the right approach. I do not expect "-q" to remove
*all* warnings, because warnings can be quite important.

Regards.

[Zdenek Kabelac]

Post by matthew patton
If the warnings are not being emitted to STDERR then that needs to be fixed
right off the bat.

The line with WARNINGs are written on STDERR, at least con recent LVM version.

Post by matthew patton
'lvs -q blah' should squash any warnings.
'lvcreate' frankly shouldn't output anything unless invoked with '-v'
anyway. So therefore '-q' should also squash warnings.

I'm not sure this is the right approach. I do not expect "-q" to remove *all*
warnings, because warnings can be quite important.

There are couple troubles - there are always a 'skilled X unskilled' users.
and also there are varying distro maintainers..

We are already facing some troubles when some distributions do make a changes
to default configuration files which are not really ideal for 'default' users
(in other words opinions about defaults are different - moreover based on
wrong blog post from users...)

So we can introduce i.e. 'novice_user = 1' in lvm.conf - but it might be
effectively dropped when package maintainer decides this way lvm2 makes less
annoying messages around some commands.

But in case of thin-pool it's better to warn-ahead instead of facing troubles
later (as full thin-pool is not going to be pleasant experience...)

So we are looking for some solution which cannot be easily 'hidden' for
everyone - so we do not end with reports about 'hidden over-provisioning'
causing system malfunctioning. Yet it should be 'easy' to bypass it for
skilled admin.


IMHO the most convenient in my eyes is a usage of some sort of 'envvar'
LVM_SUPPRESS_POOL_WARNINGS....


Since we already use similar logic to bypass i.e. FD close() warnings
LVM_SUPPRESS_FD_WARNINGS
LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES


Regards

Zdenek

[David Teigland]

Post by Zdenek Kabelac
IMHO the most convenient in my eyes is a usage of some sort of 'envvar'
LVM_SUPPRESS_POOL_WARNINGS....

I think we're looking at the wrong thing. The root problem is what we're
warning about, not that the warning is being printed. It doesn't make
sense to warn about the inherent nature of things. When peole create a
linear LV, we don't print a warning that it's not redundant. By warning
that the pool is overprovisioned, we also mislead people into thinking
that this is what they should worry about, when in fact it's free space in
the pool which is the real thing to worry about. So I think the message
should be dropped and replaced with something more useful.

[Zdenek Kabelac]

Post by David Teigland

Post by Zdenek Kabelac
IMHO the most convenient in my eyes is a usage of some sort of 'envvar'
LVM_SUPPRESS_POOL_WARNINGS....

I think we're looking at the wrong thing. The root problem is what we're
warning about, not that the warning is being printed. It doesn't make
sense to warn about the inherent nature of things. When peole create a
linear LV, we don't print a warning that it's not redundant. By warning
that the pool is overprovisioned, we also mislead people into thinking
that this is what they should worry about, when in fact it's free space in
the pool which is the real thing to worry about. So I think the message
should be dropped and replaced with something more useful.

The main purpose of the Warning is to really warn user there is NOT configured
auto-extension of thin-pool (so no threshold is setup) - so thin-pool is not
set-up in 'preferred' way (so when user counts with the fact the thin-pool
can grow and auto-extension is enabled - the warning is not printed).

I think it's really useful to give this information to the user - since from
my experience with users - many of them are simply unaware of the fact when
they take 3 snapshots they may need 3x more space of the origin volume.

So in the case users do want to have 'critical' volumes always 'safe' from
out-of-space condition - the message tells them when pool can't cover all
space for all thins.

Even in this list - people tend to think it is really an easy to just drop
snapshots like with old-snaps and they even think it will happen auto-magically.

So IMHO we are better to give user really good info about what is going on.
Once we provide more secure mechanism - we may possibly change the time and
actual printed message.

Skilled user just ignores the message - so is the major problem with it ?

Is it the 'severity' - so the message should be prefixed with "NOTE:" instead
of "WARNING:" (log_warn() -> log_print_unless_quite())

We have number of similar messages for other cases, so it's relatively common
in lvm2 to give some guidance messages to users - just this one gets some
extra tension (i.e. we can open similar discussion about handling duplicates
cases)

Regards

Zdenek

[Gionatan Danti]

Post by Zdenek Kabelac
The main purpose of the Warning is to really warn user there is NOT
configured auto-extension of thin-pool (so no threshold is setup) - so
thin-pool is not set-up in 'preferred' way (so when user counts with
the fact the thin-pool can grow and auto-extension is enabled - the
warning is not printed).
I think it's really useful to give this information to the user -
since from my experience with users - many of them are simply unaware
of the fact when they take 3 snapshots they may need 3x more space of
the origin volume.

Right, but the "skilled admin" need a command line
parameter/configuration variable to silence this warning...

Post by Zdenek Kabelac
So in the case users do want to have 'critical' volumes always 'safe'
from out-of-space condition - the message tells them when pool can't
cover all space for all thins.
Even in this list - people tend to think it is really an easy to just
drop snapshots like with old-snaps and they even think it will happen
auto-magically.
So IMHO we are better to give user really good info about what is going on.
Once we provide more secure mechanism - we may possibly change the
time and actual printed message.
Skilled user just ignores the message - so is the major problem with it ?

... because this auto-trains our eyes to automatically ignore warning
messages - which is a very bad thing IMHO.
Moreover, as the warning is emitted on STDERR, ignoring it can be
error-prone, especially in cron scripts (ie: 2>/dev/null, which is
*really* bad when it destroys/hides important error messages).

Post by Zdenek Kabelac
Is it the 'severity' - so the message should be prefixed with "NOTE:"
instead of "WARNING:" (log_warn() -> log_print_unless_quite())

I second this.

Post by Zdenek Kabelac
We have number of similar messages for other cases, so it's relatively
common in lvm2 to give some guidance messages to users - just this one
gets some extra tension (i.e. we can open similar discussion about
handling duplicates cases)

True, and I really appreciate that and the "don't let users destroy its
data" reasoning. However, when the users feel his was sufficiently
warned about thin pool fullness, we should provide a mean to silence
this (expected) error. After all, this is not due to erroneous thin pool
use. Rather, overprovisioning and snapshots are the main motivation for
the very existance of thin pool.

Thanks.

[matthew patton]

LVM and thin in particular is not for noobies or novices. If they get burned then they deserve it for using a technology they didn't bother to study and learn about beforehand. I think the warnings are gratuitous. Just like some of the other output that LVM emits like "create succeeded". Create succeeded is indicated by a 0 return code. Anything else is just noise. If the user wants noise, then need to use the '-v|--verbose' flag.

I don't think it's a bad idea to have 'LVM_SUPPRESS_WARNINGS=1' in lvm.conf.

The broader problem is LVM is entirely too chatty and every emitted message needs to be properly examined and assigned to 'verbose', 'debug', and 'normal' and likewise if it should be squelched via 'quiet' or 'double quiet'.

Commands that do listings is IMO the only place where warnings should show up, again subject to 'quiet' and the triggering threshold.

[Zdenek Kabelac]

Post by matthew patton
LVM and thin in particular is not for noobies or novices. If they get burned then they deserve it for using a technology they didn't bother to study and learn

Well it's not for novices ;) yet I believe 'lvm2' should not be an easy
weapon for mass destruction for users data - we are then 'beaten' by rumors
from the 'other side'

Post by matthew patton
"create succeeded". Create succeeded is indicated by a 0 return code. Anything else is just noise. If the user wants noise, then need to use the '-v|--verbose' flag.

lvcreate -q is then likely wanted to be 'respected' as normally lvm2 tends
to be a bit 'conversational' command.

But I think '-q' should be respected and it's not with this log_warn().

So I think conversion to log_print() level is possibly the goal here ??
(covering both side of stories).

Since as it's been said - we emit more lines per command even about successful
'middle' steps.


Regards

Zdenek