Re: [linux-lvm] exposing snapshot block device

["Tomas Dalebjörk" <tomas.dalebjork@gmail.com>]

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

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

[-- Attachment #2: Type: text/html, Size: 6031 bytes --]