All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.