Re: [linux-lvm] cache on SSD makes system unresponsive

[Zdenek Kabelac <zdenek.kabelac@gmail.com>]

Dne 21.10.2017 v 16:33 Oleg Cherkasov napsal(a):
> On 20. okt. 2017 21:35, John Stoffel wrote:
>>>>>>> "Oleg" == Oleg Cherkasov <o1e9@member.fsf.org> writes:
>>
>> Oleg> On 19. okt. 2017 21:09, John Stoffel wrote:
>>>>
>>
>> Oleg> RAM 12Gb, swap around 12Gb as well.� /dev/sda is a hardware RAID1, the
>> Oleg> rest are RAID5.
>>
>> Interesting, it's all hardware RAID devices from what I can see.
> 
> It is exactly what I wrote initially in my first message!
> 
>>
>> Can you should the *exact* commands you used to make the cache?� Are
>> you using lvcache, or bcache?� they're two totally different beasts.
>> I looked into bcache in the past, but since you can't remove it from
>> an LV, I decided not to use it.� I use lvcache like this:
> 
> I have used lvcache of course and here are commands from bash history:
> 
> lvcreate -L 1G -n primary_backup_lv_cache_meta primary_backup_vg /dev/sda5
> 
> ### Allocate ~247G ib /dev/sda5 what has left of VG
> lvcreate -l 100%FREE -n primary_backup_lv_cache primary_backup_vg /dev/sda5
> 
> lvconvert --type cache-pool --cachemode writethrough --poolmetadata 
> primary_backup_vg/primary_backup_lv_cache_meta 
> primary_backup_vg/primary_backup_lv_cache
> 
> lvconvert --type cache --cachepool primary_backup_vg/primary_backup_lv_cache 
> primary_backup_vg/primary_backup_lv
> 
> ### lvconvert failed because required some extra extends in VG so I had to 
> reduce cache LV and try again:
> 
> lvreduce -L 200M primary_backup_vg/primary_backup_lv_cache
> 


Hi

Without plans to interrupt thoughts on topic here - the explanation here is 
very simple.

Cache pool is made from 'data' & 'metadata' LV - so both needs some space.
In the case of 'cache pool' it's pretty good plan to have both device is fast 
spindle (SSD).

So can you please provide output of:

lvs -a -o+devices

so it could be easily validated both _cdata & _cmeta LV is hosted by some SSD 
device (it's not shown anywhere in the thread - so just to be sure we have 
them on right disks)

Regards

Zdenek