linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	Ilia Zykov <linux@izyk.ru>
Subject: Re: [linux-lvm] Why doesn't the lvmcache support the discard (trim) command?
Date: Fri, 19 Oct 2018 11:12:10 +0200	[thread overview]
Message-ID: <06b65c62-8ca2-0d29-b98d-1a1585141f81@redhat.com> (raw)
In-Reply-To: <de207689-775b-5c36-1443-e035f19ff65f@izyk.ru>

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

  reply	other threads:[~2018-10-19  9:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 22:56 [linux-lvm] Why doesn't the lvmcache support the discard (trim) command? Ilia Zykov
2018-10-19  9:12 ` Zdenek Kabelac [this message]
2018-10-19  9:42   ` Gionatan Danti
2018-10-19  9:49     ` Zdenek Kabelac
2018-10-19  9:55   ` Ilia Zykov
2018-10-19 10:58     ` Zdenek Kabelac
2018-10-19 12:45       ` Gionatan Danti
2018-10-19 13:08         ` Zdenek Kabelac
2018-10-19 13:16           ` Ilia Zykov
2018-10-19 17:00           ` Ilia Zykov
2018-10-22 10:54             ` Zdenek Kabelac
2018-10-19 20:54           ` Gionatan Danti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=06b65c62-8ca2-0d29-b98d-1a1585141f81@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=linux@izyk.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).