<div dir="ltr"><div>Wow!</div><div><br></div><div>Impressing.</div><div>This will make history!</div><div><br></div><div>If this is possible, than we are able to implement a solution, which can do:</div><div>- progressive block level incremental forever (always incremental on block level : this already exist)</div><div>- instant recovery to point in time (using the mentioned methods you just described)</div><div><br></div><div>For example, lets say that a client wants to restore a file system, or a logical volume to how it looked a like yesterday.</div><div>Eventhough there are no snapshot, nor any data.</div><div>Than the client (with some coding); can start from an empty volume, and re-attach a cow device, and convert that using lvconvert --merge, so that the copying can be done in background using the backup server.</div><div><br></div><div>If you forget about "how we will re-create the cow device"; and just focusing on the LVM ideas of re-attaching a cow device.</div><div>Do you think that I have understood it correctly?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors 24 okt. 2019 kl 18:01 skrev Zdenek Kabelac <<a href="mailto:zkabelac@redhat.com">zkabelac@redhat.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dne 23. 10. 19 v 13:24 Tomas Dalebjörk napsal(a):<br>
> I have tested FusionIO together with old thick snapshots.<br>
> I created the thick snapshot on a separate old traditional SATA drive, just to <br>
> check if that could be used as a snapshot target for high performance disks; <br>
> like a Fusion IO card.<br>
> For those who doesn't know about FusionIO; they can deal with 150-250,000 IOPS.<br>
> <br>
> And to be honest, I couldn't bottle neck the SATA disk I used as a thick <br>
> snapshot target.<br>
> The reason for why is simple:<br>
> - thick snapshots uses sequential write techniques<br>
> <br>
> If I would have been using thin snapshots, than the writes would most likely <br>
> be more randomized on disk, which would have required more spindles to coop <br>
> with this.<br>
> <br>
> Anyhow;<br>
> I am still eager to hear how to use an external device to import snapshots.<br>
> And when I say "import"; I am not talking about copyback, more to use to read <br>
> data from.<br>
<br>
Format of 'on-disk' snapshot metadata for old snapshot is trivial - being some<br>
header + pairs of dataoffset-TO-FROM -  I think googling will reveal couple<br>
python tools playing with it.<br>
<br>
You can add pre-created COW image to LV  with  lvconvert --snapshot<br>
and to avoid 'zeroing' metadata use option -Zn<br>
(BTW in the same way you can detach snapshot from LV with --splitsnapshot so <br>
you can look how the metadata looks like...)<br>
<br>
Although it's pretty unusual why would anyone create first the COW image with <br>
all the special layout and then merge it to LV - instead of directly <br>
merging...   There is only the 'little' advantage of minimizing 'offline' time <br>
of such device   (and it's the reason why --split exists).<br>
<br>
Regards<br>
<br>
Zdenek<br>
<br>
<br>
</blockquote></div>