|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>|
|Priority:||medium||CC:||agk, alitke, heinzm, jbrassow, msnitzer, prajnoha, prockai, thornber, zkabelac|
|Fixed In Version:||lvm2-2.02.161-1.el7||Doc Type:||Known Issue|
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).
|Last Closed:||2016-11-04 04:14:56 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1366991, 1364339, 1366176|
Description Bruno Goncalves 2016-07-11 08:46:03 UTC
Description of problem: If for some reason the size of LV during lvresize does not change it should not try to resize the FS. Version-Release number of selected component (if applicable): lvm2-2.02.160-1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Create a thinp 2.Create a FS on it mkfs.ext4 /dev/tsvg/lv1 3.Extend thin pool to use almost all space on VG lvextend -l+99%FREE tsvg/pool1 4.Try to extend LV using free space on VG, even though it does not make sense. lvextend -rf -l+99%FREE tsvg/lv1 Actual results: The LV did not change its size, but tries to resize the file system # 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) resize2fs: Invalid new size: 0 fsadm: Resize ext4 failed fsadm failed: 1 Expected results: As LV size did not change, it should not try to resize file system
Comment 2 Bruno Goncalves 2016-07-11 09:00:05 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!
Comment 3 Zdenek Kabelac 2016-07-14 11:24:53 UTC
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
Comment 5 Bruno Goncalves 2016-07-27 11:40:43 UTC
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!
Comment 7 Steven J. Levine 2016-08-17 16:12:09 UTC
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.)
Comment 8 Jonathan Earl Brassow 2016-08-17 16:27:11 UTC
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.
Comment 9 Steven J. Levine 2016-08-18 16:17:30 UTC
Jonathan: Could you check the description in the Doc Text field for the release notes? Thanks. Steven
Comment 10 Jonathan Earl Brassow 2016-08-18 16:22:59 UTC
(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." /
Comment 11 Steven J. Levine 2016-08-18 16:45:05 UTC
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.
Comment 12 Steven J. Levine 2016-08-22 12:57:46 UTC
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.
Comment 13 Steven J. Levine 2016-09-23 21:09:04 UTC
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
Comment 14 Steven J. Levine 2016-10-05 16:19:55 UTC
jonathan: can you verify that the rewritten description works here? The summary title is now about the changed exit code.
Comment 15 Jonathan Earl Brassow 2016-10-27 17:42:50 UTC
steve, I've changed the doc_text to be more clear, I hope.
Comment 16 Jonathan Earl Brassow 2016-10-27 17:43:38 UTC
*** Bug 1365186 has been marked as a duplicate of this bug. ***
Comment 18 errata-xmlrpc 2016-11-04 04:14:56 UTC
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