atom feed23 messages in com.redhat.linux-lvmRe: [linux-lvm] Using LVM Mirroring t...
FromSent OnAttachments
Ambrogio De LorenzoSep 16, 2009 6:59 am 
André GillibertSep 16, 2009 8:05 am 
Ambrogio De LorenzoSep 16, 2009 9:47 am 
Brian J. MurrellSep 16, 2009 9:58 am 
mala...@us.ibm.comSep 16, 2009 11:19 am 
Ambrogio De LorenzoSep 16, 2009 12:03 pm 
Ambrogio De LorenzoSep 16, 2009 12:15 pm 
Brian J. MurrellSep 16, 2009 12:49 pm 
André GillibertSep 16, 2009 1:03 pm 
Ambrogio De LorenzoSep 16, 2009 1:22 pm 
mala...@us.ibm.comSep 16, 2009 1:33 pm 
Kai Stian OlstadSep 16, 2009 3:03 pm 
Bryn M. ReevesSep 17, 2009 2:57 am 
Stuart D. GathmanSep 17, 2009 8:06 am 
Brian J. MurrellSep 17, 2009 8:34 am 
Stuart D. GathmanSep 17, 2009 3:49 pm 
Les MikesellSep 17, 2009 4:26 pm 
Brian J. MurrellSep 17, 2009 4:48 pm 
Stuart D. GathmanSep 17, 2009 5:57 pm 
Sven EschenbergSep 17, 2009 6:51 pm 
Stuart D. GathmanSep 17, 2009 6:55 pm 
Mark H. WoodSep 18, 2009 9:05 am 
Stuart D. GathmanSep 18, 2009 12:12 pm 
Subject:Re: [linux-lvm] Using LVM Mirroring to obtain a usable backup
From:Stuart D. Gathman (stu@bmsi.com)
Date:Sep 17, 2009 6:55:51 pm
List:com.redhat.linux-lvm

On Thu, 17 Sep 2009, Brian J. Murrell wrote:

1) Eventually you still need to copy the snapshot to a normal LV to get your performance back

Will you? When you are using the snapshot instead of the origin, you are writing to the COW already, not writing to the origin which requires a COW copy-out.

Only if you are updating an entire fragment. Otherwise, it is read/modify/write.

Furthermore, even when the snapshot is entirely filled out, the fragments are in random physical order. (Could be mitigated by smart placement in the COW based on LV size.)

Furthermore, even if you don't care about performance, you currently *still* have to copy to a real LV to take another snapshot.

Furthermore, if some future LVM version is capable of recursive snapshots, the performance issue is intensified with each snapshot layer.

Actually, that last isn't strictly true. There is the device mapper based "Zumastor" product that uses a common COW shared among many snapshots and can take multiple snapshots or snapshots of snapshots with no (additional) performance degradation. That could be a standard feature in some future LVM version.

2) (minor, but important) Another FAQ is "exactly how big do I need to make my snapshot so that it is guaranteed never to overflow".

Heh. Yeah.

This is instensified in the Zumastor idea, since overflow can potentially invalidate hundreds of snapshots, some of which could be essential (cloned virtual servers for a client). (Maybe it's best to simply revert all the Zumastor LVs to readonly in that case. Maybe it already does that.)