From: nl6720 <nl6720@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: [linux-lvm] Why isn't issue_discards enabled by default?
Date: Tue, 22 Sep 2020 12:14:19 +0300 [thread overview]
Message-ID: <2262429.nQIR6vq4BO@walnut> (raw)
In-Reply-To: <02099334-08df-112d-1d02-dd76cc5d8f65@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]
On Monday, 21 September 2020 21:51:39 EEST Zdenek Kabelac wrote:
> Dne 21. 09. 20 v 16:14 nl6720 napsal(a):
> > Hi,
> >
> > I wanted to know why the "issue_discards" setting isn't enabled by
> > default. Are there any dangers in enabling it or if not is there a
> > chance of getting the default changed?
> >
> > Also it's not entirely clear to me if/how "issue_discards" affects
> > thin pool discard passdown.
>
> Hi
>
> Have you checked it's enclosed documentation in within
> /etc/lvm/lvm.conf ?
>
> issue_discards is PURELY & ONLY related to sending discard to removed
> disk extents/areas after 'lvremove'.
>
> It is't not in ANY way related to actual discard handling of the LV
> itself. So if you have LV on SSD it is automatically processing
> discards. From the same reason it's unrelated to discard processing
> of thin-pools.
>
> And finally why we prefer issue_discards to be disabled (=0) by
> default. It's very simple - with lvm2 we try (when we can) to support
> one-command-back restore - so if you do 'lvremove' - you can use
> vgcfgrestore to restore previous metadata and you have your LV back
> with all the data inside.
>
> When you have issue_discards=1 - the device gets TRIM - so all the
> data are discarded at device level - so when you try to restore your
> previous metadata - well it's nice - but content is gone forever....
>
> If user can live with this 'risk' and prefers immediate discard -
> perfectly fine - but it should be (IMHO) admin's decision.
>
> Regards
>
> Zdenek
Thanks for your answer, so the reason it's not enabled by default is to
allow vgcfgrestore to function.
I have read /etc/lvm/lvm.conf and understand that issue_discards affects
things like lvremove. But I'd like to know, is it only for lvremove or
also lvreduce and lvconvert (--merge/--uncache)? And what is its
relation to thin_pool_discards; with issue_discards = 0 and
thin_pool_discards = passdown (both the defaults) how far down are the
discards passed?
Lastly, there's no fstrim equivalent for trimming unused space in a PV,
right? To do that I'd need to lvcreate a LV occupying all free space and
then use `lvremove --config devices/issue_discards = 1`.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2020-09-22 9:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 14:14 [linux-lvm] Why isn't issue_discards enabled by default? nl6720
2020-09-21 14:26 ` Mark Mielke
2020-09-22 8:13 ` Zdenek Kabelac
2020-09-21 18:51 ` Zdenek Kabelac
2020-09-22 9:14 ` nl6720 [this message]
2020-09-22 9:20 ` nl6720
2020-09-22 10:15 ` Zdenek Kabelac
2020-09-22 10:38 ` nl6720
2020-09-22 10:59 ` Zdenek Kabelac
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=2262429.nQIR6vq4BO@walnut \
--to=nl6720@gmail.com \
--cc=linux-lvm@redhat.com \
--cc=zkabelac@redhat.com \
/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).