[linux-lvm] Why doesn't the lvmcache support the discard (trim) command?

[Ilia Zykov]

On 19.10.2018 16:08, Zdenek Kabelac wrote:
> Dne 19. 10. 18 v 14:45 Gionatan Danti napsal(a):
>> On 19/10/2018 12:58, Zdenek Kabelac wrote:
>>> Hi
>>>
>>> Writecache simply doesn't care about caching your reads at all.
>>> Your RAM with it's page caching mechanism keeps read data as long as
>>> there is free RAM for this - the less RAM goes to page cache - less
>>> read operations remains cached.
>>
>> Hi, does it mean that to have *both* fast write cache *and* read cache
>> one should use a dm-writeback target + a dm-cache writethrough target
>> (possibly pointing to different devices)?
>>
>> Can you quantify/explain why and how faster is dm-writeback for heavy
>> write workload?
> 
> 
> 
> Hi
> 
> It's rather about different workload takes benefit from different
> caching approaches.
> 
> If your system is heavy on writes -  dm-writecache is what you want,
> if you mostly reads - dm-cache will win.
> 
> That's why there is  dmstats to also help identify hotspots and overal
> logic.
> There is nothing to win always in all cases - so ATM 2 different targets
> are provided -  NVDIMMs already seems to change game a lot...
> 
> dm-writecache could be seen as 'extension' of your page-cache to held
> longer list of dirty-pages...
> 
> Zdenek

Sorry, but I don't understand too. What be if reboot happens between data writes from the fast cache to the slow device? After reboot what data will be reads? A new data from the fast cache or an old from the slow device? And what data will be read 'dd if=/dev/cached iflag=direct'? 
Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3980 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20181019/2cd47376/attachment.p7s>