Bug 1006072 - Support lvconvert --splitsnapshot to split snapshot data and metadata out into a separate LV where it can be wiped before removing it
Summary: Support lvconvert --splitsnapshot to split snapshot data and metadata out int...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-09 23:43 UTC by Eric Harney
Modified: 2014-01-21 11:06 UTC (History)
11 users (show)

Fixed In Version: lvm2-2.02.105-1.fc21
Clone Of:
: 1056454 (view as bug list)
Environment:
Last Closed: 2014-01-21 11:06:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Eric Harney 2013-09-09 23:43:29 UTC
This is a request to add functionality to LVM to assist with the wiping of LVM volume and snapshot data.

OpenStack Cinder uses LVM to manage volumes containing data used by OpenStack VMs.  When a volume, or snapshot of a volume, is deleted, it Cinder currently performs a wipe of the data using dd if=/dev/zero.  This is done both to protect data from being exposed across different volumes and tenants, as well as to protect data from being accessed via any method (accessing the storage) after the volume/snapshot has been deleted.

This dd method is problematic because on "thick" snap LVs, the snapshot will fill up before the entire volume size has been written to the snapshot.  On thin-provisioned LVs, this has undesirable performance, since the entire snapshot is consumed by the wipe process.

https://bugzilla.redhat.com/show_bug.cgi?id=975052#c11 outlined two ideas for how to improve this situation by having LVM assist in the wipe process:
 1) Performing wipes similar to how discards are handled today
 2) Allow the delete process to detach the cow volume so that Cinder can wipe it and then delete the LV.

Current thinking is that #1 may not be suitable since it would hang other LVM operations for a long period of time.  #2 would be sufficient for this scenario.

Comment 1 Alasdair Kergon 2013-12-03 01:51:17 UTC
I am experimenting with option 2, to offer an inverse of lvconvert -s.

Comment 2 Alasdair Kergon 2013-12-03 03:46:08 UTC
# lvs
  LV    VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  lvol0 vg1  owi--- 12.00m                                      
  lvol1 vg1  swi--- 12.00m lvol0                

# lvconvert --splitsnapshot vg1/lvol1
  Logical Volume vg1/lvol1 split from its origin.

# lvs
  LV    VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  lvol0 vg1  -wi--- 12.00m                                      
  lvol1 vg1  -wi--- 12.00m                        

The snapshot may or may not be active when the command is run.

The origin may have other snapshots too which are left untouched.

After separation, provided no data got changed, the snapshot could be reinstated with lvconvert -s -Zn vg1/lvol0 vg1/lvol1.

At this stage I am only supporting the straightforward case of an original lvm2 snapshot of an origin LV without any thin volumes, mirrors, raid, pvmove, failed merging snapshots etc. involved.

If need be, we can consider support for other combinations in subsequent releases (not on this bugzilla).

Comment 3 Alasdair Kergon 2013-12-04 02:14:42 UTC
https://git.fedorahosted.org/cgit/lvm2.git/patch/?id=7b65363bf781cd58d45e2d9f12fdfed59b9dee55

Will be included in 2.02.105.


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