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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
