Created attachment 1188817 [details]
Reproducer (run as root)
Description of problem:
When calling lvextend with a size equal to the current LV size, the command should fail with rc=3. It is now failing with rc=5 which breaks its API and causes management programs to misinterpret the error.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Call lvextend on an LV using the current LV size
Command fails with rc=5
Command fails with rc=3
See test script to be attached.
This is a bugfix.
To know the size of a LV - metadata needs to be opened and parsed.
Return code 3 is returned (or should be returned) only in the case metadata were not yet opened (lock not grabbed) and invalid command line args were given.
Return code 5 is the ONLY correct one here in this case.
You can't rely on return code 3 to detect 'same size' - that's clear bug in application (and in fact this bug should have been reported)...
You are breaking a layer product and such changes should be done with care.
Please consider reverting this until we are able to adept. Changing this without any prior notice make it very hard to resolve.
*** Bug 1366176 has been marked as a duplicate of this bug. ***
(In reply to Yaniv Dary from comment #2)
> You are breaking a layer product and such changes should be done with care.
> Please consider reverting this until we are able to adept. Changing this
> without any prior notice make it very hard to resolve.
You were clearly misusing 'undocumented' observed buggy behavior. Instead you should have immediately report a bug where return code 3 has been returned after VG metadata has been parsed.
Do you expect lvm2 to support every released bug in every release forever - like having approximately 50 new config options per every version to enable/disable every bug found during develeopment ?
The only reliable method is to obtain the size explicitly and compare it, if you want to check whether or not the size is the same (or use --select). Relying on the distinction between code 3 and 5 is always going to lead to fragile code, I'm afraid. We may be rewriting more of this code soon too, which will no doubt lead to some more similar cases of individual errors changing for better overall consistency.
(In reply to Zdenek Kabelac from comment #4)
> (In reply to Yaniv Dary from comment #2)
> > You are breaking a layer product and such changes should be done with care.
> > Please consider reverting this until we are able to adept. Changing this
> > without any prior notice make it very hard to resolve.
> You were clearly misusing 'undocumented' observed buggy behavior. Instead
> you should have immediately report a bug where return code 3 has been
> returned after VG metadata has been parsed.
Can you point me to the lvm bug about "fixing" the error code when extending
We expect zero backward incompatible changes in minor versions. Changing
behaviour (even undocumented) must be done only in major version.
All we say in the man page is:
All tools return a status code of zero on success or non-zero on fail-
We can add another sentence there to make the policy clearer to people who haven't asked.
The exit code is only a guide as to whether the failure was probably due to incorrect syntax (code 3) or anything else (code 5). It was never safe to assume that code 3 meant the device was already the expected size as other problems also cause that same code. An error is an error and nothing should be relying upon the distinction between these two codes as there are various different possible causes of each. 'lvconvert' is another case being reviewed where previously accepted (but ambiguous or misleading) syntax is now being rejected outright.
We're working towards making fine-grained error codes available in future (which would be tightly-defined and supported), and the 7.3 release contains the first part of this - if operating on several objects at once in a single command, you can now find out which ones triggered the error and which were accessed OK without having to process each separately as you used to have to do.
> Can you point me to the lvm bug about "fixing" the error code when extending
> an lv?
Here is related bug 1354396.
Marius, does this affect cockpit, storaged, and their usage of lvresize?
(In reply to Stef Walter from comment #10)
> Marius, does this affect cockpit, storaged, and their usage of lvresize?
No, any non-zero exit code is treated the same.
We are merged fixed for this regression and we expect that we will be able to backport them in time for RHEL 7.3 support in RHEV. Closing.
*** This bug has been marked as a duplicate of bug 1354396 ***