[linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Mikulas Patocka]

Hi

Here I release the first experimental implementation of snapshot merging. 
Merging allows you to copy data in snapshot back to the origin device. 
Once merging starts, it runs on background. When the merging finishes (you 
see "0%" with "lvs" command), you should remove the merging snapshot with 
lvremove command.

The userspace will still be changed, the kernel is already finished (there 
are no known bugs in the kernel, I'm curious about the unknown ones :)

Merging is initiated with "lvconvert -M vg/lv_snapshot" command. When you 
initiate merging, make sure that the origin device is not mounted. 
Snapshot can be mounted while it's merging is initiated.

During merging, aby reads and writes to the origin device are identical to 
accesses to the merging snapshots.

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.

Don't try to concurrently merge more than one snapshot (the kernel refuses 
to do it, the userspace tools don't know about it --- the userspace will 
be rewritten anyway).

The patches are at:
http://people.redhat.com/mpatocka/patches/
The patches are for 2.6.26-rc4

(besides merging, there are some other bugfixes, I made for the kernel)

Mikulas

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Brian J. Murrell]

[-- 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 --]

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Chris Cox]

On Tue, 2008-06-03 at 15:26 -0400, Mikulas Patocka wrote:
> Hi
> 
> Here I release the first experimental implementation of snapshot merging. 
> Merging allows you to copy data in snapshot back to the origin device. 
> Once merging starts, it runs on background. When the merging finishes (you 
> see "0%" with "lvs" command), you should remove the merging snapshot with 
> lvremove command.

I would think this would be VERY hard to do since both the "origin" and
"snapshot" change (file deletes, etc).  Do you have a set of rules you
use for the merge?

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Stuart D. Gathman]

On Tue, 3 Jun 2008, Chris Cox wrote:

> > Here I release the first experimental implementation of snapshot merging. 
> 
> I would think this would be VERY hard to do since both the "origin" and
> "snapshot" change (file deletes, etc).  Do you have a set of rules you
> use for the merge?

Translation: KUDOS!!

-- 
	      Stuart D. Gathman <stuart@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.

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Brian J. Murrell]

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

On Tue, 2008-06-03 at 15:43 -0500, Chris Cox wrote:
> 
> I would think this would be VERY hard to do since both the "origin" and
> "snapshot" change (file deletes, etc).

I don't think it's as difficult as you are thinking it is.  You are
thinking of synchronizing filesystems, at the filesystem level, but
merging a snapshot back up into the origin does not deal with files or
even filesystems.  It deals with block devices and blocks, and is really
nothing more than a coordinated:

for each COW_block in snapshot; do
    for other_snapshot of origin; do
        copy origin[COW_block] to other_snapshot[COW_block]
        copy snapshot[COW_block] to origin[COW_block]
    done
done

> Do you have a set of rules you
> use for the merge?

There is no filesystem level merge.  There are no rules needed.

b.


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

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Chris Cox]

On Tue, 2008-06-03 at 19:38 -0400, Brian J. Murrell wrote:
> On Tue, 2008-06-03 at 15:43 -0500, Chris Cox wrote:
> > 
> > I would think this would be VERY hard to do since both the "origin" and
> > "snapshot" change (file deletes, etc).
> 
> I don't think it's as difficult as you are thinking it is.  You are
> thinking of synchronizing filesystems, at the filesystem level, but
> merging a snapshot back up into the origin does not deal with files or
> even filesystems.  It deals with block devices and blocks, and is really
> nothing more than a coordinated:
> 
> for each COW_block in snapshot; do
>     for other_snapshot of origin; do
>         copy origin[COW_block] to other_snapshot[COW_block]
>         copy snapshot[COW_block] to origin[COW_block]
>     done
> done
> 
> > Do you have a set of rules you
> > use for the merge?
> 
> There is no filesystem level merge.  There are no rules needed.

Ok... I'm still a bit confused (sorry)... I'm going to assume
a last out wins scenario with regards to meta data conflicts
... yes.. I know, I'm having a tough time separating out the
filesystem element from the block device :)

Thanks for the answer... it does make sense (just makes my
brain hurt).

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Greg Freemyer]

Your making it too complicated.

Effectively the snapshot immediately becomes the primary volume and a
bunch of stuff goes on in the background to sync the true primary and
the other snapshots to it.

After everything is in sync, the snapshot is deleted and the true
primary once again becomes the logical primary.

Greg

On Tue, Jun 3, 2008 at 8:05 PM, Chris Cox <chris_cox@stercomm.com> wrote:
> On Tue, 2008-06-03 at 19:38 -0400, Brian J. Murrell wrote:
>> On Tue, 2008-06-03 at 15:43 -0500, Chris Cox wrote:
>> >
>> > I would think this would be VERY hard to do since both the "origin" and
>> > "snapshot" change (file deletes, etc).
>>
>> I don't think it's as difficult as you are thinking it is.  You are
>> thinking of synchronizing filesystems, at the filesystem level, but
>> merging a snapshot back up into the origin does not deal with files or
>> even filesystems.  It deals with block devices and blocks, and is really
>> nothing more than a coordinated:
>>
>> for each COW_block in snapshot; do
>>     for other_snapshot of origin; do
>>         copy origin[COW_block] to other_snapshot[COW_block]
>>         copy snapshot[COW_block] to origin[COW_block]
>>     done
>> done
>>
>> > Do you have a set of rules you
>> > use for the merge?
>>
>> There is no filesystem level merge.  There are no rules needed.
>
> Ok... I'm still a bit confused (sorry)... I'm going to assume
> a last out wins scenario with regards to meta data conflicts
> ... yes.. I know, I'm having a tough time separating out the
> filesystem element from the block device :)
>
> Thanks for the answer... it does make sense (just makes my
> brain hurt).
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>



-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Brian J. Murrell]

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

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?

b.


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

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Stuart D. Gathman]

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

> directly).  How can the snapshot "immediately" become the primary volume
> if that data migration has to happen?

Just point the origin dm device to the snapshot.  Read/write will take
place to the snapshot as normal.  Meanwhile, in the background, blocks
copied from the origin, and blocks written to the snapshot, are copied
back to the origin (leaving out the details of updating other snapshots
for expositional simplicity).  The origin is inaccessible, having been pointed
at the snapshot.  When the origin is in sync, point it back, and it begins
evolving independently of the snapshot.

The origin should be closed (file systems unmounted) for the initial "point
origin to snapshot".  Any file system would be very confused to see 
the disk suddenly revert to a previous state (or even a modified previous
state in case of a read/write snapshot).

A slightly simpler way to do it would be to simply make the origin
inaccessible.  The admin would unmount origin, mount r/w snapshot,
start merge, when merge is finished, umount snapshot, remount origin.  
The purpose of redirecting the origin during the merge is to render
the 2nd unmount-mount unneccessary.

In case of a xen VM, you would destroy VM (don't bother with shutdown) or
otherwise quickly stop VM (maybe want to cleanly shutdown network connections).
Start merge on all LVs mounted by VM.  Boot VM.  If you kept a save of
the VM state with every set of snapshots, you could simply restore the VM
to the saved state after starting the merge.  The effect is that in seconds
the VM is reverted to a previous state.

Naturally, there are other pieces to make this useful.  For instance,
telling applications in the VM to get into a nice state (e.g. between
transactions) before pausing the VM to take the snapshots is helpful.  A
standard databus event of "get ready for snapshot" would be nice.  And then
there is enabling other machines on the network to get a handle on the revert.
You also need something like Zumastor so you can take lots of snapshots,
like every 15 minutes, for lots of choices for where to revert.
And then, you need differential mirroring of the snapshots (supported
by Zumastor) + VM state to a remote datacenter, so the "revert" can take place
on the remote site in case the primary site is nuked.

-- 
	      Stuart D. Gathman <stuart@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.

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Mikulas Patocka]

On Tue, 3 Jun 2008, Chris Cox wrote:

> On Tue, 2008-06-03 at 15:26 -0400, Mikulas Patocka wrote:
>> Hi
>>
>> Here I release the first experimental implementation of snapshot merging.
>> Merging allows you to copy data in snapshot back to the origin device.
>> Once merging starts, it runs on background. When the merging finishes (you
>> see "0%" with "lvs" command), you should remove the merging snapshot with
>> lvremove command.
>
> I would think this would be VERY hard to do since both the "origin" and
> "snapshot" change (file deletes, etc).  Do you have a set of rules you
> use for the merge?

The rule is: "origin must not be mounted when you start merging". 
Currently it is not enforced by the lvm tool (you damage your filesystem, 
if you merge over a mounted filesystem), in final version, there will be a 
test to refuse merging in this case.

If you merge a snapshot, you are going to lose the data in the origin. If 
you don't want to lose them, create another snapshot before you start 
merging (then, the new snapshot will contain the data in the origin).

Another rule is: while merging is in progress, don't create other 
snapshots --- well, you can, but they will contain inconsistent midstate. 
Snapshots that were created before the merging started will be preserved 
OK.

Mikulas

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Mikulas Patocka]

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

> 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? ------------^^^

Yes, there should be "any".

>>  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?

Yes. You can immediatelly mount the origin read-write and you see the 
content of the snapshot being merged.

>> 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?

Yes.

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

No.

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

No, if you block copy over /dev/vg/snapshot device, it will contain all 
the blocks (regardless if they differ from the origin or not).

There could theoretically be compare function, testing if the write equals 
to actual data and dropping the write eventually --- but it would be too 
much coding overhead for too little practical advantage.

> Now if you merge S1 up to O1, ideally S2 should be "empty".

Snapshots are never shrunk (except when being merged) --- the metadata 
format doesn't allow to remove arbitrary exception from the exception 
table.

Mikulas

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

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Mikulas Patocka]

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.

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Steeve McCauley]

Is this change meant to add cluster support for merging?  I had
been under the assumption that merging was already a feature of
snapshots.

What is the difference between the current implementation using
lvremove (which I assumed was where the COW blocks were merged back
into the original volume) and lvconvert as below?  Why was this
functionality not kept in lvremove?

Mikulas Patocka wrote:
> Hi
> 
> Here I release the first experimental implementation of snapshot 
> merging. Merging allows you to copy data in snapshot back to the origin 
> device. Once merging starts, it runs on background. When the merging 
> finishes (you see "0%" with "lvs" command), you should remove the 
> merging snapshot with lvremove command.
> 
> The userspace will still be changed, the kernel is already finished 
> (there are no known bugs in the kernel, I'm curious about the unknown 
> ones :)
> 
> Merging is initiated with "lvconvert -M vg/lv_snapshot" command. When 
> you initiate merging, make sure that the origin device is not mounted. 
> Snapshot can be mounted while it's merging is initiated.
> 
> During merging, aby reads and writes to the origin device are identical 
> to accesses to the merging snapshots.
> 
> 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.
> 
> Don't try to concurrently merge more than one snapshot (the kernel 
> refuses to do it, the userspace tools don't know about it --- the 
> userspace will be rewritten anyway).
> 
> The patches are at:
> http://people.redhat.com/mpatocka/patches/
> The patches are for 2.6.26-rc4
> 
> (besides merging, there are some other bugfixes, I made for the kernel)
> 
> Mikulas
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

-- 
Steeve McCauley
Director of Research and Development
Rackable Systems
407 McGill Street, Suite 1002
Montreal, Quebec, H2Y 2G3 (Canada)
Tel: 514-288-3343
http://www.rackable.com
:wq

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Brian J. Murrell]

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

On Wed, 2008-06-04 at 07:07 -0400, Mikulas Patocka wrote:
> 
> > 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).
> 
> No, if you block copy over /dev/vg/snapshot device, it will contain all 
> the blocks (regardless if they differ from the origin or not).

So my premise of copying from S1 to S2 and the result that S2 would only
contain real blocks for what differs to the origin and pointers for
blocks that don't differ is false?

> There could theoretically be compare function, testing if the write equals 
> to actual data and dropping the write eventually --- but it would be too 
> much coding overhead for too little practical advantage.

For certain use cases I think this would be a great advantage.  Think
about this:

     1. Create an LV and install a linux distro into it.
     2. Make a snapshot and customize to the settings for a given
        configuration (i.e. a group of hosts)
     3. Now I want to make an (initially) identical (to the snapshot
        customized in step 2) snapshot for each node in that
        configuration

Being able to do:

# lvcreate -L5G -n pristine node_group
[ install linux distro into /dev/node_group/pristine ]
# lvcreate -s -L$size -n config1_master pristine
# for node in $nodelist; do
>     lvcreate -s -L$size -n $node pristine
>     dd if=/dev/node_group/config1_master of=/dev/node_group/$node
> done

And have each of those snapshots be as efficient as config1_master.

> Snapshots are never shrunk (except when being merged) --- the metadata 
> format doesn't allow to remove arbitrary exception from the exception 
> table.

Pity.

b.


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

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Mikulas Patocka]

On Wed, 4 Jun 2008, Steeve McCauley wrote:

> Is this change meant to add cluster support for merging?  I had
> been under the assumption that merging was already a feature of
> snapshots.

My implementation has nothing to do with clustering.

I think there were some userspace programs for off-line merging of 
inactive snapshots. My implementation works in kernel and can be used 
while the snapshot is mounted.

> What is the difference between the current implementation using
> lvremove (which I assumed was where the COW blocks were merged back
> into the original volume) and lvconvert as below?  Why was this
> functionality not kept in lvremove?

lvremove drops the snapshot and forgets its content. lvconvert -M copies 
the snapshot to the origin (I'm now working on to let it automatically 
drop the snapshot when the merging finishes).

Mikulas

> Mikulas Patocka wrote:
>> Hi
>> 
>> Here I release the first experimental implementation of snapshot merging. 
>> Merging allows you to copy data in snapshot back to the origin device. Once 
>> merging starts, it runs on background. When the merging finishes (you see 
>> "0%" with "lvs" command), you should remove the merging snapshot with 
>> lvremove command.
>> 
>> The userspace will still be changed, the kernel is already finished (there 
>> are no known bugs in the kernel, I'm curious about the unknown ones :)
>> 
>> Merging is initiated with "lvconvert -M vg/lv_snapshot" command. When you 
>> initiate merging, make sure that the origin device is not mounted. Snapshot 
>> can be mounted while it's merging is initiated.
>> 
>> During merging, aby reads and writes to the origin device are identical to 
>> accesses to the merging snapshots.
>> 
>> 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.
>> 
>> Don't try to concurrently merge more than one snapshot (the kernel refuses 
>> to do it, the userspace tools don't know about it --- the userspace will be 
>> rewritten anyway).
>> 
>> The patches are at:
>> http://people.redhat.com/mpatocka/patches/
>> The patches are for 2.6.26-rc4
>> 
>> (besides merging, there are some other bugfixes, I made for the kernel)
>> 
>> Mikulas
>> 
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
> -- 
> Steeve McCauley
> Director of Research and Development
> Rackable Systems
> 407 McGill Street, Suite 1002
> Montreal, Quebec, H2Y 2G3 (Canada)
> Tel: 514-288-3343
> http://www.rackable.com
> :wq
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] ANNOUNCE: an experimental implementation of snapshot merging

[Mikulas Patocka]

On Wed, 4 Jun 2008, Brian J. Murrell wrote:

> On Wed, 2008-06-04 at 07:07 -0400, Mikulas Patocka wrote:
>>
>>> 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).
>>
>> No, if you block copy over /dev/vg/snapshot device, it will contain all
>> the blocks (regardless if they differ from the origin or not).
>
> So my premise of copying from S1 to S2 and the result that S2 would only
> contain real blocks for what differs to the origin and pointers for
> blocks that don't differ is false?

Yes, it's false.

If you overwrite a snapshot, you always allocate new exceptions of the 
written blocks --- regardless if the blocks differ from the origin or not.

>> There could theoretically be compare function, testing if the write equals
>> to actual data and dropping the write eventually --- but it would be too
>> much coding overhead for too little practical advantage.
>
> For certain use cases I think this would be a great advantage.  Think
> about this:
>
>     1. Create an LV and install a linux distro into it.
>     2. Make a snapshot and customize to the settings for a given
>        configuration (i.e. a group of hosts)
>     3. Now I want to make an (initially) identical (to the snapshot
>        customized in step 2) snapshot for each node in that
>        configuration
>
> Being able to do:
>
> # lvcreate -L5G -n pristine node_group
> [ install linux distro into /dev/node_group/pristine ]
> # lvcreate -s -L$size -n config1_master pristine
> # for node in $nodelist; do
>>     lvcreate -s -L$size -n $node pristine
>>     dd if=/dev/node_group/config1_master of=/dev/node_group/$node
>> done
>
> And have each of those snapshots be as efficient as config1_master.

You can do this if you copy the exception store (i.e. don't copy 
/dev/vg/snap or /dev/mapper/vg-snap --- instead, copy 
/dev/mapper/vg-snap-cow). Copy it to a new linear logical volume and then 
use lvconvert -s to turn it into a snapshot. When you copy 
/dev/mapper/vg-snap-cow, the snapshot and origin must be idle --- 
otherwise you'd be copying data while it's being modified.

Mikulas