[linux-lvm] exposing snapshot block device

Tomas Dalebjörk tomas.dalebjork at gmail.com
Tue Nov 5 20:56:27 UTC 2019


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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20191105/09fce7f3/attachment.htm>


More information about the linux-lvm mailing list