Re: [linux-lvm] Why isn't issue_discards enabled by default?

[nl6720 <nl6720@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On Tuesday, 22 September 2020 12:14:19 EEST nl6720 wrote:
> 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?
> 

Oops, rereading it, lvreduce is actually mentioned in /etc/lvm/lvm.conf. 
Well, the question about lvconvert and thin pool still stands.

> 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 --]