Bug 2048160 - [RFE] LVM Thin: Support running thin_discard before activating a thin pool
Summary: [RFE] LVM Thin: Support running thin_discard before activating a thin pool
Keywords:
Status: NEW
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: LVM Team
QA Contact: cluster-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-29 20:01 UTC by Demi Marie Obenour
Modified: 2024-04-27 05:52 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:
pm-rhel: lvm-technical-solution?
pm-rhel: lvm-test-coverage?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github QubesOS/qubes-issues/5426 0 None None None 2022-01-29 20:01:19 UTC

Description Demi Marie Obenour 2022-01-29 20:01:19 UTC
Description of problem:
To ensure that blocks freed by deleting a thin pool LV are discarded,
one must run blkdiscard on the thin pool LV before deleting it.  This
is slow and unreliable.  Instead, LVM could run thin_trim on the
metadata and data LVs before activating the pool.  This would
automatically discard all blocks in the pool that are no longer needed.

Version-Release number of selected component (if applicable):
This feature has not been implemented in any version of LVM2 to date.

How reproducible:
100%

Steps to Reproduce:

1. Have a system where thin pool LVs are frequently created and destroyed.
2. Try to figure out how to ensure that blocks used only by to-be-destroyed
   thin pool LVs are discarded.

Actual results:
There is no solution better than running blkdiscard on the LV before removing
it, which is slow, unreliable, and interferes with other I/O unless manually
chunked.

Expected results:
LVM2 can be configured to run thin_trim before activating the pool,
automatically discarding the unneeded blocks.

Additional info:
Linux currently implements on a thin pool LV inefficiently,
which is one reason that this is a problem in practice.

Comment 1 Demi Marie Obenour 2022-01-29 20:06:06 UTC
This is likely to be significant for those who use LVM thin provisioning on
top of VDO, as VDO is itself a form of thin provisioning and requires discards
to be passed down from upper layers.


Note You need to log in before you can comment on or make changes to this bug.