Thanks,

That really helped me to understand how the snapshot works.
Last question:
- lets say that block 100 which is 1MB in size is in the cow device, and a write happen that wants to something or all data on that region of block 100.
Than I assume; based on what have been previously said here, that the block in the cow device will be overwritten with the new changes.

Regards Tomas

Den tis 5 nov. 2019 kl 17:40 skrev Mikulas Patocka <mpatocka@redhat.com>:


On Mon, 4 Nov 2019, Tomas Dalebjörk wrote:

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

Merging starts from the last block on the lv00-snap device and it proceeds
backward to the beginning.

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

Yes.

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

It only waits if you attempt to read or write the block that is currently
being copied.

If you read data that hasn't been merged yet, it reads from the snapshot,
if you read data that has been merged, it reads from the origin, if you
read data that is currently being copied, it waits.

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

No.

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

The changes will be written to the lv00-snap device.

If you write data that hasn't been merged yet, the write is redirected to
the lv00-snap device. If you write data that has already been merged, the
write is directed to the origin device. If you write data that is
currently being merged, it waits.

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

You can't have read-only COW device. Both metadata and data on the COW
device are updated during the merge.

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

Mikulas