Linux LVM users
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging
Date: Wed, 4 Jun 2008 07:11:20 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0806040707450.2902@engineering.redhat.com> (raw)
In-Reply-To: <1212548240.29076.215.camel@pc.ilinx>

On Tue, 3 Jun 2008, Brian J. Murrell wrote:

> On Tue, 2008-06-03 at 20:20 -0400, Greg Freemyer wrote:
>> Your making it too complicated.
>>
>> Effectively the snapshot immediately becomes the primary volume
>
> How can that be done?  I thought the snapshot was simply a device which
> upon creation (i.e. before any writes to the origin) is just a series of
> block-by-block pointers to the origin.  As blocks in the origin are
> changed, those blocks are copied down to the snapshot are replace the
> pointer to itself.
>
> So in the case where the origin has had 50% of it's blocks updated, in
> order for the snapshot to become the origin, that 50% which has been
> written down in to the snapshot need to be written back up into the
> origin (along with any blocks which were changed in the snapshot
> directly).  How can the snapshot "immediately" become the primary volume
> if that data migration has to happen?

The requests are transparently re-routed to the merging snapshot.

So, when you start merging, the origin device physically contains the old 
data (that are being overwritten by data from the snapshot), but when you 
make a read or write request to the origin, that request causes look-up in 
the exception table of the merging snapshot and if a match is found, the 
request is remapped to the snapshot.

So the merging snapshot and the origin appear to contain the same data. 
(in the final version, one of them will not appear in the list of logical 
volumes, so that it won't confuse the user --- but this is only userspace 
thing)

Mikulas

> b.

  parent reply	other threads:[~2008-06-04 11:11 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
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 [this message]
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=Pine.LNX.4.64.0806040707450.2902@engineering.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=linux-lvm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox