[linux-lvm] Why isn't issue_discards enabled by default?
nl6720
nl6720 at gmail.com
Tue Sep 22 10:38:05 UTC 2020
On Tuesday, 22 September 2020 13:15:19 EEST Zdenek Kabelac wrote:
> Dne 22. 09. 20 v 11:14 nl6720 napsal(a):
> > 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
> There is currently one known exception - pvmove - which is not trivial
> to resolve. All other 'removals' go through standard extent release
> and can be discarded when wanted (unless we missed some other
> use-case).
> > relation to thin_pool_discards; with issue_discards = 0 and
> > thin_pool_discards = passdown (both the defaults) how far down are
> > the discards passed?
>
> thin-pool is using LVs - so this is again about handling the discard
> on a _tdata LV and it is completely unrelated to issue_discards
> setting.
from lvmthin(7):
"passdown: Process discards in the thin pool (as with nopassdown), and
pass the discards down the the underlying device. This is the default
mode."
It's the "underlying device" that's confusing me.
> > 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`.
>
> Well there is one easily 'scriptable'
>
> You can simply allocate the free space in your VG (lvcreate
> -l100%FREE) and then simply use 'blkdiscard
> /dev/vg/my_discardable_lv'
> Once finished - release the LV.
>
> We may eventually introduce some 'pollable' support as some discards
> can take extremely long time depending on type of a device.
> However at this moment this is not really seen as priority...
>
> Regards
>
> Zdenek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20200922/d1d5cefa/attachment.sig>
More information about the linux-lvm
mailing list