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

[Gionatan Danti]

Il 19-09-2017 17:30 Zdenek Kabelac ha scritto:
> 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...

> 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).

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

I second this.

> 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.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8