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

[Zdenek Kabelac]

Dne 22. 09. 20 v 12:38 nl6720 napsal(a):

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,

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.


All it means is -  _tdata LV is placed on some PV/device.

So the passdown means - TRIM goes through thinLV to thin-pool and then through
its _tdata LV it lands on 'underlying device' aka PV used for this LV.

If there is better and less confusing way how to describe this case,
feel free to submit better wording.

Zdenek

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[nl6720]

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



signature.asc
Description: This is a digitally signed message part.
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[Zdenek Kabelac]

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.




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





___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[nl6720]

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`.



signature.asc
Description: This is a digitally signed message part.
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[nl6720]

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`.


signature.asc
Description: This is a digitally signed message part.
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[Zdenek Kabelac]

Dne 21. 09. 20 v 16:26 Mark Mielke napsal(a):
On Mon, Sep 21, 2020 at 10:14 AM nl6720 > wrote:


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.


Historically, there have been dangers. Even today, there might still be 
dangers - although, I believe Linux (and other OS) may disable the feature in 
hardware which is known to behave improperly.


If you do research and ensure you are using a good storage drive, there should 
not be any problems. I enable issue_discards on all systems I work with at 
home and work, and have not encountered any problems. But, I also don't buy 
cheap drives with questionable namebrands.


It's pretty common for settings such as these to be more conservative, to 
ensure that the users who are willing to accept the risk (no matter how small) 
can turn it on as an option, and the users who are unaware or might not have 
evaluated the risk, cannot blame the software vendors for losing their data. 
In the case of LVM - it's not LVM's fault that some drives might lose your 
data when discard is sent. But, users of LVM might blame LVM.


Hi

So let's repeat again -  issue_discards  has nothing to do with discard 
handling of the LV itself.


If the LV is sitting on top of SSD - it will receive discard/TRIM no matter
what is set in this issue_discard setting - it could be  0 or 1 and LV will be 
discarded.


Anyone can very easily try - create some small simple LV on top SSD - or 
thinLV then create i.e.  mkfs.ext4 and use 'fstrim -v'.

With discardable device you will get nice print about discarded region -
then play with issue_discards setting - there will be no change...

Setting issue_discards only matters when you run 'lvremove' and your VG is
maybe on some 'provisioned' storage and you pay for used space - in this case 
released extents in VG will receive TRIM - so VG will eat less physical

space on such storage.

So keeping this setting 0 is perfectly fine and allows users to revert many 
lvm2 operation if they've made a mistake.


When setting is 1 - most of lvm2 commands have NO way back - once done, all 
data is gove - which can be quite fatal if you have i.e. very similar LV names...


No distribution should be setting issue_discards to '1' by default - it should 
be always changed by admin so he is aware of consequences.


Regards

Zdenek

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

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

[Zdenek Kabelac]

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

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/