Dne 19. 10. 18 v 11:55 Ilia Zykov napsal(a):
On 19.10.2018 12:12, Zdenek Kabelac wrote:
Dne 19. 10. 18 v 0:56 Ilia Zykov napsal(a):
Maybe it will be implemented later? But it seems to me a little
strange when there is no way to clear the cache from a garbage.
Maybe I do not understand? Can you please explain this behavior.
For example:
Hi
Applying my brain logic here:
Cache (by default) operates on 32KB chunks.
SSD (usually) have the minimal size of trimable block as 512KB.
Conclusion can be there is non-trivial to even implement TRIM support
for cache - as something would need to keep a secondary data structure
which would keep the information about which all cached blocks are
completely 'unused/trimmed' and available from a 'complete block trim'
(i.e. something like when ext4 implements 'fstrim' support.)
Second thought - if there is a wish to completely 'erase' cache - there
is very simple path by using 'lvconvert --uncache' - and once the cache
is needed again, create cache again from scratch.
Note - dm-cache is SLOW moving cache - so it doesn't target acceleration
one-time usage - i.e. if you read block just once from slow storage - it
doesn't mean it will be immediately cached.
Dm-cache is about keeping info about used blocks on 'slow' storage (hdd)
which typically does not support/implemnent TRIM. There could be
possibly a multi-layer cache, where even the cached device can handle
TRIM - but this kind on construct is not really support and it's even
unclear if it would make any sense to introduce this concept ATM (since
there would need to be some well measurable benefit).
And final note - there is upcoming support for accelerating writes with
new dm-writecache target.
Regards
Zdenek
Thank you, I supposed it is so.
One more little question about dm-writecache:
The description says that:
"It doesn't cache reads because reads are supposed to be cached in page cache
in normal RAM."
Is it only mean, missing reads not promoted to the cache?
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.
It's probably worth to add comment about older dm-cache - where read access is
basically accounted (so the most used blocks cat be promoted to caching
storage device) - if the reads are served by your page-cache - they can't be
accounted - that's just to explain why repeated reads of the same block which
is basically served by your page-cache doesn't lead to quick promotion of
block to cache like one could expect without thinking about details behind....
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
