All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
To: Peri Hankey <mpah@thegreen.co.uk>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: A snapshot is not (really) a cow
Date: Sun, 26 Sep 2004 15:48:42 +0100	[thread overview]
Message-ID: <20040926144842.GA7435@cl.cam.ac.uk> (raw)
In-Reply-To: <4156AA1E.5070308@thegreen.co.uk>

On Sun, Sep 26, 2004 at 12:38:06PM +0100, Peri Hankey wrote:
> I always found the lvm2 'snapshot' terminology confusing - the thing 
> created as a 'snapshot' is what accepts changes while a backup is made 
> of the original volume.

I don't think that's the terminology the LVM2 people use.  The regular
use is to create a snapshot and backup this snapshot while you keep
using the original.

> # drat - I needed another domain
> lvcreate -L512M -s -n u4 /dev/vmgroup/root_file_system
> ... nasty messages .... all xenU domains dead ....
> ... lmv2 system in inconsistent state ...
> ... /dev/vmgroup/u4 doesn't exist ...
> ... /dev/mapper/root_file_system-u4 does exist ...

This should work, if it doesn't then it would seem to be a bug in
LVM2.  Since you mention out of memory error messages, are you sure
that you're not running out of memory in dom0?

> The problem is that the 'snapshot' cows hold onto each other's tails - 
> they seem to be held in a list linked (I think) from the original 
> logical volume (here /dev/vmgroup/root_file_system). For their intended 
> use as enabling backup, this seems to be meant to allow writes to the 
> original volume to be propagated to all 'snapshots' created against that 
> volume - there are comments about getting rid of the 'snapshots' after 
> the backup has been done because this propagation of writes hits 
> performance.
>
> For my requirements, and I imagine for most others reading this list, 
> all of this is superfluous. I don't need
> 
>     original -> snap1 -> snap2 -> snap3 ...

This is not the layout LVM2 uses.  If you look at the output of
``dmsetup table'', you'll see that each snapshot is independent
and only refers to the device it is a snapshot of and to its cow
device which will hold modifications.

> so that I can't create a new snap4 while any of the others are in use.
> 
> I just need
> 
>     original <- cow1
>     original <- cow2
>     original <- cow3
>     original <- cow4
>     ...
> 
> where A '<-' B means B is a cow image of A, and where each of the cows 
> is independent of the others so that a new cow can be created at any 
> time, regardless how many others are active.

This is the layout LVM2 uses.  And it is indeed simple (and should be
quite robust) as long as you don't want to write to the original.
If you write to the original, you will have to copy the changed
blocks to every snapshot's cow device.  I think I've seen this
fail when having multiple snapshots and writing to the original.
But since you didn't write to the original (and one generally doesn't
need/want to write to the original in our case), that problem
is unlikely to be relevant to the failure you've seen.

    christian



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

  reply	other threads:[~2004-09-26 14:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-26 11:38 A snapshot is not (really) a cow Peri Hankey
2004-09-26 14:48 ` Christian Limpach [this message]
2004-09-26 19:05   ` Peri Hankey
2004-09-26 19:28     ` Ian Pratt
2004-09-26 21:29       ` Peri Hankey
2004-09-26 21:44         ` Ian Pratt
2004-09-27  7:57           ` Peri Hankey
2004-09-27 10:12             ` Ian Pratt
2004-09-27  8:40           ` Peri Hankey
     [not found]             ` <20040927103914.GA8152@yuri.org.uk>
2004-09-27 11:29               ` Peri Hankey
2004-09-27 13:35   ` Peri Hankey
2004-09-27 17:21     ` Christian Limpach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040926144842.GA7435@cl.cam.ac.uk \
    --to=christian.limpach@cl.cam.ac.uk \
    --cc=mpah@thegreen.co.uk \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.