Bug 1354396
| Summary: | lvmresize: resize of unchanged LV should not try to resize FS | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Bruno Goncalves <bgoncalv> |
| Component: | lvm2 | Assignee: | Zdenek Kabelac <zkabelac> |
| lvm2 sub component: | Changing Logical Volumes | QA Contact: | Bruno Goncalves <bgoncalv> |
| Status: | CLOSED ERRATA | Docs Contact: | Steven J. Levine <slevine> |
| Severity: | medium | ||
| Priority: | medium | CC: | agk, alitke, heinzm, jbrassow, msnitzer, prajnoha, prockai, thornber, zkabelac |
| Version: | 7.2 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.161-1.el7 | Doc Type: | Known Issue |
| Doc Text: |
Exit code returned from the "lvextend" command has changed
Previously, if the "lvextend" or "lvresize" commands were run in a way that would result in no change to the size of the logical volume, an attempt was still made to resize the file system. The unnecessary attempt to resize the file system is no longer made and this has caused the exit code of the command to change. LVM makes no guarantees of the consistency of exit codes beyond zero (success) and non-zero (failure).
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-04 04:14:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1364339, 1366176, 1366991 | ||
|
Description
Bruno Goncalves
2016-07-11 08:46:03 UTC
On RHEL-7.2 it does: lvm2-2.02.130-5.el7.x86_64 # lvextend -rf -l+99%FREE tsvg/lv1 fsck from util-linux 2.23.2 /dev/mapper/tsvg-lv1: 11/10240 files (9.1% non-contiguous), 6175/40960 blocks Size of logical volume tsvg/lv1 unchanged from 40.00 MiB (10 extents). Logical volume lv1 successfully resized. resize2fs 1.42.9 (28-Dec-2013) The filesystem is already 40960 blocks long. Nothing to do! It's diverged already in release 2.02.141 and should be addressed by this upstream commit: https://www.redhat.com/archives/lvm-devel/2016-July/msg00166.html It works well on lvm2-2.02.161-2 # lvextend -l+99%FREE tsvg/pool1 Size of logical volume tsvg/pool1_tdata changed from 128.00 MiB (32 extents) to 488.00 MiB (122 extents). Logical volume tsvg/pool1_tdata successfully resized. # lvextend -rf -l+99%FREE tsvg/lv1 fsck from util-linux 2.23.2 /dev/mapper/tsvg-lv1: 11/10240 files (9.1% non-contiguous), 6175/40960 blocks Size of logical volume tsvg/lv1 unchanged from 40.00 MiB (10 extents). Logical volume tsvg/lv1 successfully resized. resize2fs 1.42.9 (28-Dec-2013) The filesystem is already 40960 blocks long. Nothing to do! Jonathan: I'm looking this over for inclusion in the release notes, and it seems to be a bug fix rather than a feature. Is that correct? If so I can change the Doc Type to Bug Fix. (If not, then I'm not really sure how to describe this as a feature.) It is a bug fix, but it also has release note implications in that the return code for this command is changing. While users should rely on zero vs non-zero values, we have seen one case where someone inferred a specific meaning to one of the return codes - and that came to bite them later. Jonathan: Could you check the description in the Doc Text field for the release notes? Thanks. Steven (In reply to Steven J. Levine from comment #9) > Jonathan: > > Could you check the description in the Doc Text field for the release notes? > Thanks. > > Steven Not quite right. It still returns an error code, but that error code has changed from the previous code. s/ "lvextend command no longer attempts to resize file system when size of logical volume does not change, and no longer returns an error code" / "The lvextend command no longer attempts to resize a file system when the size of the logical volume hasn't changed. The exit code returned from the command has also changed as a result." / That editied sentence is actually the title of the description -- a release note entry has a summary title and then a fuller description -- so it should not really be two sentences. I tried to make this one sentence, and then noted the "as a result" in the description that follows. (But in any case I didn't say that it no longer returns an error code but instead now say that the exit code it returns has changed...) This still seems too long to serve as a title, but I can't figure out how to make it any shorter and still say both what the bug fix is and note how this changes the exit code. It turns out that the title is too long for the format of a release note description title, so I removed the error code info from the title itself. It is still in the description and I think is apparent enough -- it's a brief enough description with a clear enough "as a result" that it calls out this issue. The other option is just to title this something like: "Error code from lvextend command has changed when size of volume remains unchanged", but I think including that info in the description should work. Jonathan: I changed this to a known feature. The only thing I changed in the release note description in the doc text is the title/first line. Does this work? Steven jonathan: can you verify that the rewritten description works here? The summary title is now about the changed exit code. steve, I've changed the doc_text to be more clear, I hope. *** Bug 1365186 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-1445.html |