Bug 1443880

Summary: lvconvert should not accept --cachepolicy cleaner and --cachemode writeback together
Product: Red Hat Enterprise Linux 7 Reporter: Bruno Goncalves <bgoncalv>
Component: lvm2Assignee: David Teigland <teigland>
lvm2 sub component: Cache Logical Volumes QA Contact: Bruno Goncalves <bgoncalv>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: agk, heinzm, jbrassow, mcsontos, msnitzer, prajnoha, zkabelac
Version: 7.4   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: lvm2-2.02.171-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 21:52:19 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:

Description Bruno Goncalves 2017-04-20 08:11:10 UTC 
Description of problem:
It is possible to use lvconvert to set --cachepolicy cleaner and --cachemode writeback together, although this does not make sense.

Version-Release number of selected component (if applicable):
lvm2-2.02.169-1.el7.x86_64
device-mapper-1.02.138-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Create LV devices
fallocate -l 500M cache_policy.img
losetup /dev/loop0 cache_policy.img
fallocate -l 200M pool_policy.img
losetup /dev/loop1 pool_policy.img
vgcreate cache_sanity /dev/loop0 /dev/loop1
lvcreate -L 100M -n display_cache cache_sanity /dev/loop0
lvcreate -L 100M -n pool cache_sanity /dev/loop1
lvcreate -L 12M -n pool_meta cache_sanity /dev/loop1

2. Convert the pool
lvconvert --yes --type cache-pool --cachepolicy cleaner --cachemode writeback -c 32 --poolmetadata cache_sanity/pool_meta cache_sanity/pool



Actual results:
lvconvert --yes --type cache-pool --cachepolicy cleaner --cachemode writeback -c 32 --poolmetadata cache_sanity/pool_meta cache_sanity/pool
  WARNING: Converting logical volume cache_sanity/pool and cache_sanity/pool_meta to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Converted cache_sanity/pool to cache pool.

Expected results:
The command should fail or give some warning message

Additional info:
This might cause problems when using the device

lvconvert --yes --type cache --cachepool cache_sanity/pool cache_sanity/display_cache
  device-mapper: reload ioctl on  (253:3) failed: Invalid argument
  Failed to lock logical volume cache_sanity/display_cache.

lvremove -f cache_sanity/display_cache
  WARNING: Reading VG cache_sanity from disk because lvmetad metadata is invalid.
  Logical volume "display_cache" successfully removed
Comment 1 Zdenek Kabelac 2017-04-20 08:21:10 UTC 
Yep - original version of lvm2 supported this combination by chance - however cleaner policy with writeback is not supported anymore -  libdm is automatically always using 'writethrough' cache mode with cleaner policy.


We have couple choices here:


1.
Reject command because converting or creating any cached LV with cleaner policy is not really usable.


2.
Reject command because  cleaner + writeback is not supported.


3.
Automagically switch to 'writethrough' with some printed WARNING.
Comment 2 David Teigland 2017-05-05 15:03:53 UTC 
https://sourceware.org/git/?p=lvm2.git;a=commit;h=df5fd5ae8843e6bbbe7f61c4919a594693639a60
Comment 3 Marian Csontos 2017-05-24 12:23:33 UTC 
Exception?

Upstream: Yes

Justification: Better checks to avoid meaningless combination of options.
Comment 5 Bruno Goncalves 2017-05-29 09:34:56 UTC 
Tested with lvm2-2.02.171-2.el7, the commands reject the options as expected:

# lvconvert --yes --type cache-pool --cachepolicy cleaner --cachemode writeback -c 32 --poolmetadata cache_sanity/pool_meta cache_sanity/pool
  Cache mode "writeback" is not compatible with cache policy "cleaner".
Comment 6 errata-xmlrpc 2017-08-01 21:52:19 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://access.redhat.com/errata/RHBA-2017:2222