Bug 1354396 - lvmresize: resize of unchanged LV should not try to resize FS
Summary: lvmresize: resize of unchanged LV should not try to resize FS
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: Bruno Goncalves
Steven J. Levine
URL:
Whiteboard:
: 1365186 (view as bug list)
Depends On:
Blocks: 1366991 1364339 1366176
TreeView+ depends on / blocked
 
Reported: 2016-07-11 08:46 UTC by Bruno Goncalves
Modified: 2016-11-04 04:14 UTC (History)
9 users (show)

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).
Clone Of:
Environment:
Last Closed: 2016-11-04 04:14:56 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1445 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2016-11-03 13:46:41 UTC
Red Hat Bugzilla 1365186 None CLOSED lvextend changed return code when called with current LV size 2019-06-01 03:12:46 UTC

Internal Links: 1365186

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


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