RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 654691 - LVMs commands is inconsistent - sometimes return error when already in state and sometimes fail
Summary: LVMs commands is inconsistent - sometimes return error when already in state ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: pre-dev-freeze
: ---
Assignee: Alasdair Kergon
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 656240 756082
TreeView+ depends on / blocked
 
Reported: 2010-11-18 15:47 UTC by Eduardo Warszawski
Modified: 2023-03-08 07:25 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-18 23:34:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Eduardo Warszawski 2010-11-18 15:47:45 UTC
Description of problem:
lvchange -p rw fails if the LV is writeable.

Version-Release number of selected component (if applicable):
  LVM version:     2.02.72(2) (2010-07-28)
  Library version: 1.02.53 (2010-07-28)
  Driver version:  4.17.0


How reproducible:
Set rw permission on a writeable volume.

Steps to Reproduce:
1.Verify that LV permission attr = w
2. lvchange -p rw vg_test/lvol0
3.
  
Actual results:
  Logical volume "lvol0" is already writable

rc = 5

Expected results:


Additional info:
Activation of an already active volume returns rc = 0.

Comment 2 Alasdair Kergon 2010-11-18 16:35:21 UTC
There was a long discussion, never satisfactorily resolved: does successful exit status indicate "the action you requested succeeded" or "the device is now in the state you requested"?

Originally I wrote the tools with the latter in mind, but I was later persuaded to change to the former.  Maybe one day we'll make it configurable...

Comment 3 Ayal Baron 2010-11-21 08:50:56 UTC
(In reply to comment #2)
> There was a long discussion, never satisfactorily resolved: does successful
> exit status indicate "the action you requested succeeded" or "the device is now
> in the state you requested"?
> 
> Originally I wrote the tools with the latter in mind, but I was later persuaded
> to change to the former.  Maybe one day we'll make it configurable...

Fine, but the current behaviour is inconsistent.
For example, removing a non-existent tag does not return an error.
activating an already active LV does not return an error.

If you want to return an error in such cases (which I agree is the right behaviour) then the error code cannot be RC but a distinct return code (needs to be handled by machine so text is not a good option.
So I'm reopening and renaming the bug.

Comment 4 Alasdair Kergon 2010-11-23 02:45:01 UTC
Other than handling specific cases that cause specific problems, I'm not convinced it's worth the effort and knock-on problems a full audit would involve.
Maybe this'll just happen by default when the tools are converted to use the library (which *will* necessarily have to be stricter).

Comment 5 Alasdair Kergon 2010-11-23 02:46:01 UTC
(In short, I am still not clear in my own mind what 'correct' behaviour always is: there are plenty of difficult cases to decide.)

Comment 6 Ayal Baron 2010-11-24 14:53:45 UTC
(In reply to comment #5)
> (In short, I am still not clear in my own mind what 'correct' behaviour always
> is: there are plenty of difficult cases to decide.)

I'm not sure there is a "correct" behaviour.  However, I do think LVM should be consistent.
Personally, I prefer not having this fail as it complicates things when we try to run multiple actions in a single command (e.g. deltag and addtag together).
In any event, current behaviour is not only inconsistent but there is no way to differentiate between the different states using the rc.

Comment 8 Suzanne Logcher 2011-03-28 21:14:52 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains 
unresolved, it has been rejected as it is not proposed as an 
exception or blocker.

Red Hat invites you to ask your support representative to 
propose this request, if appropriate and relevant, in the 
next release of Red Hat Enterprise Linux.

Comment 11 Alasdair Kergon 2012-07-31 23:11:37 UTC
Another example:

VG has lvol1 and lvol2.
lvol1 has tag tag1.
lvol2 is untagged.

You run lvchange --deltag tag1 VG

What's the right return code?

Success, because tag1 was present on lvol1 and got removed?

Failure, because lvol2 doesn't possess tag1 but you asked it to remove the tag from every LV in the VG and one of the LVs doesn't have the tag?


lvchange -ay VG/lvol1 VG/lvol2
and lvol1 is already active but lvol2 is not?

Success because everything's active afterwards?

Failure because lvol1 was already active so couldn't be activated?

Is
lvchange -ay VG
the same?

Is
vgchange -ay VG
different because as a vg* command the 'unit' under consideration is the VG rather than the LV, and the VG was not fully active before, but is afterwards - so that's always success.


I don't see any reasonable way to resolve the incompatible requirements from different users apart from making the return code configurable so the user decides whether they want an error or not in these cases.

What we'd have to do is create the configuration option, attempt to define the behaviour unambiguously along the lines I suggested (including the types of cases in this comment), then gradually migrate the tools across to work the new way.

Potentially it could be done by introducing a new error code
#define EALREADY_IN_STATE 2
instead of ECMD_FAILED (5)
(renumbering existing 2->3 and 3->4 as they are more serious and the highest error code wins when combining errors)
and treating the error the same as ECMD_PROCESSED (1) if the config setting tells us to.

Comment 12 Alasdair Kergon 2012-07-31 23:14:12 UTC
(that'd be an internal mapping, externally we shouldn't change existing codes so it might appear as code 4 externally)

Comment 17 Alasdair Kergon 2015-10-16 18:40:12 UTC
Still no clarity on the best way to procede - deferring.

Comment 19 Jonathan Earl Brassow 2016-01-18 23:34:17 UTC
This will go on forever - reopen when it is a problem or when the issue is taken-up.  Re-closing like was done after comment 2 in 2010.


Note You need to log in before you can comment on or make changes to this bug.