docs(lvm-local-storage): considerations for striped vs dm-thin#1075
Open
abonillabeeche wants to merge 9 commits into
Open
docs(lvm-local-storage): considerations for striped vs dm-thin#1075abonillabeeche wants to merge 9 commits into
abonillabeeche wants to merge 9 commits into
Conversation
Add a brief comparison of the two volume group types to help operators pick the right StorageClass for their workload, and append a small "Additional Notes" section covering thin-pool tuning, VM disk-bus recommendation, and Longhorn v2 coexistence. Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
abonillabeeche
force-pushed
the
docs-lvm-considerations
branch
from
July 10, 2026 00:45
63af2f8 to
1f4ccc8
Compare
Comment on lines
+107
to
+116
| ### Considerations: `striped` vs `dm-thin` | ||
|
|
||
| Both volume group types are fully supported. The choice depends on how the workload will use snapshots and how the pool capacity will be shared. | ||
|
|
||
| - **`striped`** is a good fit for workloads that mostly need direct volume performance across the physical devices in the volume group. Each logical volume gets its full requested capacity at provision time. Snapshots are provisioned as separate LVs sized to the origin's full capacity — a snapshot of a 100 GiB volume reserves an additional 100 GiB of volume group space at creation, regardless of how much data has actually been written to the origin. | ||
|
|
||
| - **`dm-thin`** is a good fit for virtual machine workloads that take snapshots or clones, and for environments that want to over-provision pool capacity. Thin volumes consume physical space only as blocks are written to them, and snapshots are true copy-on-write at the thin-pool chunk level — a fresh snapshot of a 100 GiB volume adds effectively zero pool capacity at creation and only grows as changed blocks accumulate. | ||
|
|
||
| If regular snapshots are expected, `dm-thin` is generally the right choice for VM workloads. | ||
|
|
Contributor
There was a problem hiding this comment.
I moved the text to the procedure above. Please remove these lines.
Contributor
Author
There was a problem hiding this comment.
Done in commit c36d7d7 — removed the ### Considerations: striped vs dm-thin section (now redundant with your rewritten Volume Group Type step above). Kept the trailing For more information, see [StorageClass] link as a standalone pointer. Signed off with a Co-authored-by: trailer for you since the guidance came from your review.
Contributor
Author
There was a problem hiding this comment.
Please verify!
Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
Jillian moved the striped vs dm-thin explanation into the procedure step above (Volume Group Type), so the standalone section is now duplicate content. The "For more information, see [StorageClass]" link is kept. Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Alejandro Bonilla <abonilla@suse.com>
|
Tick the box to add this pull request to the merge queue (same as
|
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds two small pieces to the LVM Local Storage add-on documentation:
stripedvsdm-thinsection right after the StorageClass creation step, to help operators pick the right volume group type at the moment they are configuring it.dm-thinpool (chunk zeroing, metadata size).virtio-scsifor VM disks backed by LVM CSI.global_filter).Same content is applied to both:
docs/advanced/addons/lvm-local-storage.md(main)versioned_docs/version-v1.8/advanced/addons/lvm-local-storage.md(v1.8)Motivation
Both volume group types are already listed as supported, but the doc doesn't currently guide the reader on when to pick one over the other. In particular, the fact that
stripedsnapshots reserve the origin's full capacity at creation time (versusdm-thinsnapshots being effectively free at creation) is important for anyone planning to take regular snapshots on their VM workloads.The Longhorn v2 coexistence note references harvester/harvester#11098 for background.
Notes
Documentation-only. No behavior changes.