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>,
	nl6720 <nl6720@gmail.com>
Subject: Re: [linux-lvm] Why isn't issue_discards enabled by default?
Date: Mon, 21 Sep 2020 20:51:39 +0200	[thread overview]
Message-ID: <02099334-08df-112d-1d02-dd76cc5d8f65@redhat.com> (raw)
In-Reply-To: <4972578.pTZnC5dHRY@walnut>

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

  parent reply	other threads:[~2020-09-21 18:51 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 [this message]
2020-09-22  9:14   ` nl6720
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=02099334-08df-112d-1d02-dd76cc5d8f65@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=nl6720@gmail.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).