Thanks for feedback.

Let me try to type different scenarios:

We have an origin volume, lets call it: /dev/vg00/lv00

We convert a snapshot volume to origin volume, lets call it: /dev/vg00/lv00-snap

- all blocks has been changed, and are represented in the /dev/vg00/lv00-snap, when we start the lvconvert process

I assume that something reads the data from /dev/vg00/lv00-snap and copy that to /dev/vg00/lv00

It will most likely start from the first block, to the last block to copy.

The block size is 1MB on /dev/vg00/lv00-snap, and we have for simplicity the same block size on the origin /dev/vg00/lv00

Scenario 1: A read comes want to read block LP 100, but lvconvert has not yet copied that LP block.

Will the read comes from /dev/vg00/lv00-snap directly and delivered to requestor?

Or will lvconvert prioritize to copy data from /dev/vg00/lv00-snap to /dev/vg00/lv00 for that block, and let the requestor wait until the copying has been completed, so that a read operation can happen from origin?

Or will the requestor have to wait until the copy data from /dev/vg00/lv00-snap to /dev/vg00/lv00 for that block has been completed, without any prioritization?

Scenario 2: A write comes want to write block LP 100, but lvconvert has not yet copied that LP block (yes, I do understand that origin is hidden now)

Will lvconvery prioritize to copy data from /dev/vg00/lv00-snap to /dev/vg00/lv00 for that block, and let the requestor write the changes directly on the origin after the copying has been performed?

Or will the write be blocked until lvconvert has finished the copying of the requested block, and than a write can be accepted to the origin?

Or where will the changes be written?

It is important for me to understand, as the backup device that I want to map as a COW device is a read only target, and is not allowed to be written to.

If read happends from the backup COW device, and writes happends to the origin, than it is possible to create an instant recovery.

If writes happends to the backup COW device, than it not that easy to implement a instance reovery solution, as the backup device is write protected.

Thanks in advance.

Den mån 4 nov. 2019 kl 11:07 skrev Zdenek Kabelac <zkabelac@redhat.com>:

Dne 04. 11. 19 v 6:54 Tomas Dalebjörk napsal(a):
> Hi
>
> I have some additional questions related to this.
> regarding this statement:
> “ While the merge is in progress, reads or writes to the origin appear as they
> were directed to the snapshot being merged. ”
>
> What exactly does that mean?
>
> Will that mean that before changes are being placed on the origin device, it
> has to first:
> read the data from the snapshot back to origin, copy the data back from origin
> to the snapshot, and than after that allow changes to happen?
> if that is the case, does it keep track of that this block should not be
> copied again?

Hi

When the 'merge' is in progress - your 'origin' is no longer accessible
for your normal usage. It's hiddenly active and only usable by snapshot-merge
target)

So during 'merging' - you can already use you snapshot like if it would be and
origin - and in the background there is a process that reads data from
'snapshot' COW device and copies them back to hidden origin.
(this is what you can observe with 'lvs' and copy%)

So any 'new' writes to such device lends at right place - reads are either
from COW (if the block has not yet been merged) or from origin.

Once all blocks from 'COW' are merged into origing - tables are remapped again
so all 'supportive' devices are removed and only your 'now fully merged'
origin becomes present for usage (while still being fully online)

Hopefully it gets more clear.

For more explanation how DM works - probably visit:
http://people.redhat.com/agk/talks/

> and will the ongoing merge priorities this block before the other background
> copying?
>
> how about read operations ?
> will the requested read operations on the origin volume be prioritized before
> the copying of snapshot data?

The priority is that you always get proper block.
Don't seek there the 'top most' performance - the correctness was always the
priority there and for long time there is no much devel effort on this ancient
target - since thin-pool usage is simply way more superior....

1st. note - major difficulty comes from ONLINE usage. If you do NOT need
device to be online (aka you keep 'reserve' copy of device) - you can merge
things directly into a device - and I simply don't see why you would want to
complicate this whole with extra step of transforming data into COW format
first and the do online merge.

2nd. note - clearly one cannot start 'merge' of snapshot into origin while
such origin device is in-use (i.e. mounted) - as that would lead to
'modification' of such filesystem under its hands.

Regards

Zdenek