Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1512134 - RFE: expose "Physical block growth of too few blocks" error to user
Summary: RFE: expose "Physical block growth of too few blocks" error to user
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: vdo
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Matthew Sakai
QA Contact: Jakub Krysl
URL:
Whiteboard:
: 1542488 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-10 23:59 UTC by Corey Marthaler
Modified: 2019-03-06 02:09 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-04 20:15:14 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Corey Marthaler 2017-11-10 23:59:09 UTC
Description of problem:
It appears vdo knows the reason growing wont work (the underlying storage wasn't extended enough), so expose that instead of an ioctl failure.


lvcreate  --virtualsize 10G -T snapper_thinp/POOL -n origin
vdo create --name virt_vdovolume --device /dev/snapper_thinp/origin

Placing an EXT filesystem on origin volume
mke2fs 1.42.9 (28-Dec-2013)
Mounting origin volume

[root@mckinley-04 ~]# df -h
/dev/mapper/virt_vdovolume          9.8G   37M  9.2G   1% /mnt/origin

[root@mckinley-04 ~]# lvextend -L +500M /dev/snapper_thinp/origin
  Size of logical volume snapper_thinp/origin changed from 10.00 GiB (2560 extents) to <10.49 GiB (2685 extents).
  Logical volume snapper_thinp/origin successfully resized.

[root@mckinley-04 ~]# vdo growPhysical --name virt_vdovolume
vdo: ERROR - Cannot prepare to grow physical on VDO virt_vdovolume; device-mapper: message ioctl on virt_vdovolume  failed: Input/output error
vdo: ERROR - device-mapper: message ioctl on virt_vdovolume  failed: Input/output error

Nov 10 17:40:30 mckinley-04 kernel: kvdo22:dmsetup: Preparing to resize physical to 2749440
Nov 10 17:40:30 mckinley-04 kernel: kvdo: dmsetup: mapToSystemError: mapping internal status code 2065 (kvdo: VDO_INCREMENT_TOO_SMALL: kvdo: Physical block growth of too few blocks) to EIO
Nov 10 17:40:30 mckinley-04 vdo: ERROR - Cannot prepare to grow physical on VDO virt_vdovolume; device-mapper: message ioctl on virt_vdovolume  failed: Input/output error
Nov 10 17:40:30 mckinley-04 vdo: ERROR - device-mapper: message ioctl on virt_vdovolume  failed: Input/output error


[root@mckinley-04 ~]# lvextend -L +10G /dev/snapper_thinp/origin
  Size of logical volume snapper_thinp/origin changed from <10.49 GiB (2685 extents) to <20.49 GiB (5245 extents).
  Logical volume snapper_thinp/origin successfully resized.

# now it appears to work
[root@mckinley-04 ~]# vdo growPhysical --name virt_vdovolume
Nov 10 17:41:34 mckinley-04 kernel: kvdo22:dmsetup: Preparing to resize physical to 5370880
Nov 10 17:41:34 mckinley-04 kernel: kvdo22:dmsetup: Done preparing to resize physical
Nov 10 17:41:34 mckinley-04 kernel: kvdo22:dmsetup: suspending device 'virt_vdovolume'
Nov 10 17:41:34 mckinley-04 kernel: kvdo22:packerQ: compression is disabled
Nov 10 17:41:34 mckinley-04 kernel: kvdo22:packerQ: compression is enabled
Nov 10 17:41:34 mckinley-04 kernel: kvdo22:dmsetup: device 'virt_vdovolume' suspended
Nov 10 17:41:37 mckinley-04 kernel: kvdo22:dmsetup: Physical block count was 2621440, now 5370880
Nov 10 17:41:37 mckinley-04 kernel: kvdo22:dmsetup: resuming device 'virt_vdovolume'
Nov 10 17:41:37 mckinley-04 kernel: kvdo22:dmsetup: device 'virt_vdovolume' resumed

[root@mckinley-04 ~]# lvs -a -o +devices
  LV              VG               Attr       LSize   Pool Origin Data%  Meta% Devices               
  POOL            snapper_thinp    twi-aot---   6.00g             4.28   3.61  POOL_tdata(0)         
  [POOL_tdata]    snapper_thinp    Twi-ao----   6.00g                          /dev/mapper/mpatha1(1)
  [POOL_tmeta]    snapper_thinp    ewi-ao----   4.00m                          /dev/mapper/mpathe1(0)
  [lvol0_pmspare] snapper_thinp    ewi-------   4.00m                          /dev/mapper/mpatha1(0)
  origin          snapper_thinp    Vwi-aot--- <20.49g POOL        1.25


Version-Release number of selected component (if applicable):
vdo-6.1.0.34-8    BUILT: Fri Nov  3 06:58:45 CDT 2017
kmod-kvdo-6.1.0.34-7.el7    BUILT: Fri Nov  3 06:44:06 CDT 2017

Comment 4 Matthew Sakai 2018-02-20 22:56:15 UTC
*** Bug 1542488 has been marked as a duplicate of this bug. ***

Comment 9 corwin 2018-12-04 20:15:14 UTC
The standard for this type of issue as per lvm is for the user to look in the log. Since we already meet that standard, there is nothing more to do.

Comment 10 Miroslav Suchý 2018-12-10 09:08:37 UTC
I consider myself power user - however it would take me some time to investigate the LVM log. This is not user-friendly. I would appreciate at least mentioning "please check /var/log/lvm2.log for more information".

Please consider re-openening this bug. It does not need to be for RHEL, for upstream is just fine.


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