+++ This bug was initially created as a clone of Bug #1148592 +++

+++ This bug was initially created as a clone of Bug #1135639 +++

Description of problem:

Despite claiming to support it, 'lvconvert --type cache-pool --cachemode
writethrough' silently creates a cache pool (and thus eventually a
cache) that is actually operating in writeback mode, thus exposing the
user to a completely unexpected possibility of data loss.

(I rate this as a high impact issue because of the potential for
unexpected data loss, in fact data loss that the user thought they
were explicitly insuring against by specifying writethrough instead of
writeback caching.)

I expect that this is an upstream bug.

Version-Release number of selected component (if applicable):

lvm2-2.02.106-1.fc20.x86_64

Steps to Reproduce:

Assume that you have an initial volume group testing and a logical
volume in it testing/test that you wish to add a writethrough cache
to. Then:

 # lvcreate -L 5G -n cache_data testing
 # lvcreate -L 500M -n cache_meta testing
 # lvconvert --type cache-pool --cachemode writethrough --poolmetadata testing/cache_meta testing/cache_data
 # lvconvert --type cache --cachepool testing/cache_data testing/test
 testing/test is now cached.

At this point the dm-cache device is created and set up. It should be
in writethrough mode, because that is what we set when we created the
cache-pool LV. However:

 # dmsetup status testing-test
 0 10485760 cache 8 174/128000 128 3/81920 37 79 0 0 0 3 0 1 writeback 2 migration_threshold 2048 mq 10 random_threshold 4 sequential_threshold 512 discard_promote_adjustment 1 read_promote_adjustment 4 write_promote_adjustment 8

The actual dm-cache device is in writeback mode, not writethrough (the
'1 writeback' in the status line). The dm-cache device is capable of
being in writethrough mode if we fiddle with it:

 # dmsetup table testing-test
 0 10485760 cache 253:5 253:4 253:6 128 0 default 0
 # dmsetup reload testing-test --table '0 10485760 cache 253:5 253:4 253:6 128 1 writethrough default 0'
 # dmsetup suspend testing-test; dmsetup resume testing-test
 # dmsetup status testing-test
 0 10485760 cache 8 174/128000 128 3/81920 49 67 0 0 0 0 0 1 writethrough 2 migration_threshold 2048 mq 10 random_threshold 4 sequential_threshold 512 discard_promote_adjustment 1 read_promote_adjustment 4 write_promote_adjustment 8

It now reports '1 writethrough'.

However if we reboot the machine this dm-cache device will go right back
to being in writeback mode.

--- Additional comment from Jonathan Earl Brassow on 2014-09-16 23:21:18 EDT ---

Fix committed upstream:
commit 9d57aa9a0fe00322cb188ad1f3103d57392546e7
Author: Jonathan Brassow <jbrassow>
Date:   Tue Sep 16 22:19:53 2014 -0500

    cache-pool:  Fix specification of cachemode when converting to cache-pool
    
    Failure to copy the 'feature_flags' lvconvert_param to the matching
    lv_segment field meant that when a user specified the cachemode argument,
    the request was not honored.


This problem is also observered on RHEL 6.6

Version-Release number of selected component (if applicable):
2.6.32-504.el6.x86_64

lvm2-2.02.111-2.el6.x86_64