DescriptionChris Siebenmann
2014-08-29 20:32:47 UTC
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.
Comment 1Jonathan Earl Brassow
2014-09-17 03:21:18 UTC
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.
For what it's worth, this seems to be fixed in the current Fedora 21 version
of lvm2, lvm2-2.02.115-2.fc21.x86_64. I no longer have convenient Fedora 20
machines to test on so I don't know its status there.