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@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
