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 <mpato...@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
_______________________________________________ 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/
