Bug 1420906 - [RFE] Raid synchronization should known to use 'SSD' with zeroing
Summary: [RFE] Raid synchronization should known to use 'SSD' with zeroing
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: 2.02.169
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Heinz Mauelshagen
QA Contact: cluster-qe@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-09 20:35 UTC by Zdenek Kabelac
Modified: 2019-01-18 15:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-01-18 15:33:36 UTC
rule-engine: lvm-technical-solution?
rule-engine: lvm-test-coverage?

Attachments (Terms of Use)

Description Zdenek Kabelac 2017-02-09 20:35:39 UTC
Description of problem:

When 'raid' is made from SSD with working zeroing feature (whitelisted in kernel or whatever else that would mean) - raid 'sync' should avoid useless syncing and just 'TRIM' both legs and have raid in sync.

Likely lvm2 should be able to recognize this state and prepare raid/mirror automatically in-sync state.

Version-Release number of selected component (if applicable):
lvm 2.02.169

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 1 Heinz Mauelshagen 2019-01-18 15:33:36 UTC
Triming/discarding any storage device as requested doesn't make sense for various reasons:

- discards can take (too) long depending on their implementation
- the RAID device on top can be written to immediately after creation, thus
  it's not trivial to allow that in parallel with large and slow discard processing
- on upgrades from linear we need to assume the full content need resynchronizing

Closing, because this is an optimization for the very case of raid1/10/4/5 creation
and initial resynchronization (raid6 requires it) which is costly to implement.

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