Red Hat Bugzilla – Bug 1347008
warning emitted when overprovisioning, even though expected use case
Last modified: 2016-07-27 14:34:29 EDT
Description of problem: when creating a new thin volume where pool overprovisioned, warning is emitted, despite this being normal workflow Version-Release number of selected component (if applicable): master branch tip as of 2016-06-15 How reproducible: always Steps to Reproduce: lvcreate larger volume than pool free space Actual results: $ sudo lvcreate -n thin1 --thin-pool pool0 -s vg0/thin0 WARNING: Sum of all thin volume sizes (16.00 GiB) exceeds the size of thin pool vg0/pool0 and the amount of free space in volume group (5.53 GiB)! Expected results: no warning should be emitted, as this is normal/expected use case of thin volumes. Additional info: this is log and/or command line pollution. most uses of thin volumes are for overprovisioning. even if not, this is expected use case, this does not deserve to have a warning emitted from logs every time, it is normal and expected behavior. at the very least, lvm.conf should have a setting to remove this, or it should only be emitted when verbose > 0. I think this warning is very confusing and it made me wonder if my understanding of thin volumes was broken. Even though one does not have to overprovision thin volumes, this is a very normal, routine use case of thin volumes; a warning should not be emitted. It was not always emitted either btw... also see conversation at http://osdir.com/ml/linux-lvm/2016-04/msg00033.html which I found when searching for a way to stifle this. code site is at pool_check_overprovisioning() L325, also note that 'test/shell/thin-overprovisioning.sh' seems to rely on this output.
The warning is intentional and until lvm2 will enhance it policy logic - it will stay as is. The warning is remanding user who has over-provisioned space in the whole VG, that lvm2 can't fulfill even with automic resize the complete write and will likely cause serious problems to your operating systems. As we now, the WARNING is important for a user to realize possible problems. Note - over-prosioning is not meant to be used to 'fake' the non-existing space - it's rather about adding the space when needed. Once we have more fine-grained policy logic we may tune better even this warning logic - ATM however the warning will remain as is.
The problem this message is trying to address is people who run the command without understanding the implications of over-provisioning. We're open to suggestions for improved forms of words to use.
the problem is not the wording it's the pollution/noise on my terminal and logs, I don't need ”handholding mode” but there is no way to turn it off. it's like saying ”warning: thin volumes are thin!” overprovisioning is a very common, possibly most common use of lvm. and there are many cases when the space will never be needed such as throwaway volumes to test things where it's known write blocks will never exceed free space during lifetime at least please provide lvm.conf setting to disable this warning even if it defaults off
I agree that this warning is excessively nannying users. I think it should just be dropped entirely. If people are using thin provisioning without the most basic knowledge about it, then the warning is going to be equally meaningless to them. There's a problem somewhere else if people end up having thin provisioning without knowing what it is. People have to go to a bit of effort to set up and create lvm thin provisioning, and someone going through that while remaining clueless about it doesn't add up. If there cases where people end up having thin provisioning "automatically" without being forced to first understand the dangers and specific responsibilities, then that needs to be stopped. Or, if something somewhere is automatically setting up lvm thin provisioning for poeple, then that something must set it up in a restricted way so that it's entirely safe to use without the user knowing or doing anything. We must trust that a user who sets up thin provisioning themselves understands it and not nanny them.
My future plan here is something like: vgcreate/vgchange --overprovisioning y|n So this way lvm2 is being aware user takes all the responsibilities over the missing spaces and may even give up maintaining _pmspare and few other controlling mechanism. We cannot easily use lvm.conf here as we have already seen d/effect on all Ubuntu/Debian distros where package maintainer decides to use 'wrong' defaults for options like issue_discards. So we do not want to provide this 'shutdown' mechanism here - which would be instantly eliminated for users' eye by 'wise' package maintainer decision.
that sounds ok to have a bit for whether to allow overprovision, however, an lvm.conf setting still makes sense now, this is decision of administrator or even distro maintainer, such as expert distro or newbie distro, intended audience may have different default. I do not think issue_discards is analogous because there is little reason not to enable discards, and multiple layers (besides lvm) in which their use could be disabled on platforms with real hardware bugs from discards, whereas overprovisioning is normal usage of lvm thin volumes and having a knob for admin to squelch is very legitimate in thin volume cases (which are in fact common). Anyways I don't think distro maintainers should be stopped from being stupid by the software creator. You ship with defaults, they override if they are stupid, it's on them. However if resistance is really that strong, I personally can live with waiting for attribute/policy bit... reasonable enough, at least it'll go away sometime, but I still think it doesn't belong there in the first place :-) Thanks in any case.
issue_discards is similar in that, just like thin provisioning, you are well advised to understand the detailed implications before using it. So with issue_discards, we made it too easy for people to configure their systems inappropriately, and now with over-provisioning in response to people getting into difficulties and coming to us for help, we've added so many warnings that we're annoying people who *do* understand what they are doing! The challenge is to find the right balance between those two extremes.
(In reply to Scott Mcdermott from comment #6) > that sounds ok to have a bit for whether to allow overprovision, however, an > lvm.conf setting still makes sense now, this is decision of administrator or > even distro maintainer, such as expert distro or newbie distro, intended > audience may have different default. > > I do not think issue_discards is analogous because there is little reason > not to enable discards, and multiple layers (besides lvm) in which their use > could be disabled on platforms with real hardware bugs from discards, > whereas overprovisioning is normal usage of lvm thin volumes and having a > knob for admin to squelch is very legitimate in thin volume cases (which are > in fact common). It is quite well analogous - since users misunderstand what 'issue_discards' option is about. For common LV to handle TRIM - you surely DO NOT need this setting at all - it works perfectly, this option is purely related to 'LV size reduce or removal', however it has major side effect about losing any ability to revert this last step - LV will restore device mapping - but it's content is already gone, and we have had quite a few issues... So basically on any Debian based distro running on SSD you cannot revert last LVM operation (with vgcfgrestore) and this is seen as purely variant for 'experts' with proper backups - not for average user who often does make some mistake (recursive lvremove is so easy to run....) So the setting should be mostly strictly used if VG sits on some provisioned space - and removed LV space needs to be returned... On standard use-path: lvcreate + mkfs - you get whole device TRIM-ed with mkfs... So it's quite similar as letting user overprovision pool easily and run out of space. Then again he may face pretty severe data loss - since handling of the system on this corner state has still a big room for improvement (it's complex set of issue which being resolved...) > > Anyways I don't think distro maintainers should be stopped from being stupid > by the software creator. You ship with defaults, they override if they are > stupid, it's on them. It's not about being stopped - but rather preventing making mistakes. We have learned few lessons already.... > However if resistance is really that strong, I personally can live with > waiting for attribute/policy bit... reasonable enough, at least it'll go > away sometime, but I still think it doesn't belong there in the first place > :-) > > Thanks in any case. We will provide something - yet it needs to fit wider picture (more fine grained policy definitions....)
I suggest two configurable warnings be printed whenever the VG is read: 1. Warn when thin pool usage reaches a configurable percent. 2. Warn when thin pool overprovisioning reaches a configurable amount. 1. With thin_pool_warn_usage_percent=75, reading the VG will warn about any thin pool that has reached 75% full. Set to 0, no warning is printed. # lvs vg WARNING: thin pool "foo" is 75% full. 2. With thin_pool_warn_overprovision_amount="1G", reading the VG will warn when a thin pool's virtual space exceeds the physical space by 1G or more. Set to 0, no warning is printed. # lvs vg WARNING: thin pool "foo" virtual space (101 G) exceeds physical space (100 G). I don't think there would be very much opposition to enabling these warnings by default because they can be disabled. --- A possible addition to 1 would be to include information about autoextend in that warning. If autoextend is disabled, "... is 75% full. (autoextend is disabled)" If autoextend is enabled, "... is 75% full. (autoextend is enabled at 90% full)"
If autoextend is enabled, but the VG will not have space when the autoextend threshold is reached, "... is 75% full. (autoextend will require vgextend)"