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

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

[nl6720]

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

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Mark Mielke]

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

On Mon, Sep 21, 2020 at 10:14 AM nl6720 <nl6720@gmail.com> 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.

-- 
Mark Mielke <mark.mielke@gmail.com>

[-- Attachment #2: Type: text/html, Size: 1829 bytes --]

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

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 <nl6720@gmail.com 
> <mailto:nl6720@gmail.com>> 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

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

[nl6720]

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

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

[nl6720]

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

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

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

[nl6720]

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

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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