* [linux-lvm] Why isn't issue_discards enabled by default?
@ 2020-09-21 14:14 nl6720
2020-09-21 14:26 ` Mark Mielke
2020-09-21 18:51 ` Zdenek Kabelac
0 siblings, 2 replies; 9+ messages in thread
From: nl6720 @ 2020-09-21 14:14 UTC (permalink / raw)
To: linux-lvm
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-21 14:14 [linux-lvm] Why isn't issue_discards enabled by default? nl6720
@ 2020-09-21 14:26 ` Mark Mielke
2020-09-22 8:13 ` Zdenek Kabelac
2020-09-21 18:51 ` Zdenek Kabelac
1 sibling, 1 reply; 9+ messages in thread
From: Mark Mielke @ 2020-09-21 14:26 UTC (permalink / raw)
To: LVM general discussion and development
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-21 14:26 ` Mark Mielke
@ 2020-09-22 8:13 ` Zdenek Kabelac
0 siblings, 0 replies; 9+ messages in thread
From: Zdenek Kabelac @ 2020-09-22 8:13 UTC (permalink / raw)
To: LVM general discussion and development, Mark Mielke
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-21 14:14 [linux-lvm] Why isn't issue_discards enabled by default? nl6720
2020-09-21 14:26 ` Mark Mielke
@ 2020-09-21 18:51 ` Zdenek Kabelac
2020-09-22 9:14 ` nl6720
1 sibling, 1 reply; 9+ messages in thread
From: Zdenek Kabelac @ 2020-09-21 18:51 UTC (permalink / raw)
To: LVM general discussion and development, nl6720
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-21 18:51 ` Zdenek Kabelac
@ 2020-09-22 9:14 ` nl6720
2020-09-22 9:20 ` nl6720
2020-09-22 10:15 ` Zdenek Kabelac
0 siblings, 2 replies; 9+ messages in thread
From: nl6720 @ 2020-09-22 9:14 UTC (permalink / raw)
To: LVM general discussion and development, Zdenek Kabelac
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-22 9:14 ` nl6720
@ 2020-09-22 9:20 ` nl6720
2020-09-22 10:15 ` Zdenek Kabelac
1 sibling, 0 replies; 9+ messages in thread
From: nl6720 @ 2020-09-22 9:20 UTC (permalink / raw)
To: LVM general discussion and development, Zdenek Kabelac
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-22 9:14 ` nl6720
2020-09-22 9:20 ` nl6720
@ 2020-09-22 10:15 ` Zdenek Kabelac
2020-09-22 10:38 ` nl6720
1 sibling, 1 reply; 9+ messages in thread
From: Zdenek Kabelac @ 2020-09-22 10:15 UTC (permalink / raw)
To: nl6720, LVM general discussion and development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-22 10:15 ` Zdenek Kabelac
@ 2020-09-22 10:38 ` nl6720
2020-09-22 10:59 ` Zdenek Kabelac
0 siblings, 1 reply; 9+ messages in thread
From: nl6720 @ 2020-09-22 10:38 UTC (permalink / raw)
To: LVM general discussion and development, Zdenek Kabelac
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [linux-lvm] Why isn't issue_discards enabled by default?
2020-09-22 10:38 ` nl6720
@ 2020-09-22 10:59 ` Zdenek Kabelac
0 siblings, 0 replies; 9+ messages in thread
From: Zdenek Kabelac @ 2020-09-22 10:59 UTC (permalink / raw)
To: nl6720, LVM general discussion and development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-09-22 10:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-21 14:14 [linux-lvm] Why isn't issue_discards enabled by default? nl6720
2020-09-21 14:26 ` Mark Mielke
2020-09-22 8:13 ` Zdenek Kabelac
2020-09-21 18:51 ` Zdenek Kabelac
2020-09-22 9:14 ` nl6720
2020-09-22 9:20 ` nl6720
2020-09-22 10:15 ` Zdenek Kabelac
2020-09-22 10:38 ` nl6720
2020-09-22 10:59 ` Zdenek Kabelac
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).