[linux-lvm] Using LVM Mirroring to obtain a usable backup

Stuart D. Gathman stuart at bmsi.com
Fri Sep 18 01:55:51 UTC 2009


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.)

-- 
	      Stuart D. Gathman <stuart at bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.




More information about the linux-lvm mailing list