All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Alasdair G Kergon <agk@redhat.com>, Milan Broz <mbroz@redhat.com>
Subject: Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging
Date: Tue, 03 Jun 2008 16:32:47 -0400	[thread overview]
Message-ID: <1212525167.29076.191.camel@pc.ilinx> (raw)
In-Reply-To: <Pine.LNX.4.64.0806031516380.20514@engineering.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On Tue, 2008-06-03 at 15:26 -0400, Mikulas Patocka wrote:
> Hi

> Merging allows you to copy data in snapshot back to the origin device. 

Cool.

> During merging, aby
typo? ------------^^^
>  reads and writes to the origin device are identical to 
> accesses to the merging snapshots.

So the origin looks 100% merged as soon as the merging starts?

> There may be multiple snapshots while one of them is being merged --- 
> exceptions in other snapshots are being allocated and there snapshots are 
> kept stable.

So basically, before blocks are copied up from the merging snapshot to
the origin, the blocks to be overwritten (in the origin) are first
copied down to other snapshots of the same origin?

Is it smart about a block that is to be copied up to the origin being
the same as the corresponding blocks in peer snapshots?  By "smart" I
mean erase the block in the peer's snapshot and put back the pointer up
to the origin.

A pedantic example would be to create an origin, O1 and then a snapshot
of O1 called S1.  Make a bunch of changes to S1 and then create another
snapshot of O1 called S2 and then block copy from S1 to S2 (presumably,
although I don't know for sure, S2 only contains the same changed blocks
as S1).  Now if you merge S1 up to O1, ideally S2 should be "empty".

> Don't try to concurrently merge more than one snapshot

Heh.

b.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-06-03 20:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03 19:26 [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging Mikulas Patocka
2008-06-03 20:32 ` Brian J. Murrell [this message]
2008-06-04 11:07   ` Mikulas Patocka
2008-06-04 14:07     ` Brian J. Murrell
2008-06-05 15:09       ` Mikulas Patocka
2008-06-03 20:43 ` Chris Cox
2008-06-03 20:51   ` Stuart D. Gathman
2008-06-03 23:38   ` Brian J. Murrell
2008-06-04  0:05     ` Chris Cox
2008-06-04  0:20       ` Greg Freemyer
2008-06-04  2:57         ` Brian J. Murrell
2008-06-04  3:23           ` Stuart D. Gathman
2008-06-04 11:11           ` Mikulas Patocka
2008-06-04 10:56   ` Mikulas Patocka
2008-06-04 14:01 ` Steeve McCauley
2008-06-05 15:01   ` Mikulas Patocka

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=1212525167.29076.191.camel@pc.ilinx \
    --to=brian@interlinx.bc.ca \
    --cc=agk@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=mbroz@redhat.com \
    /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.