[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-lvm
Subject: Re: [linux-lvm] exposing snapshot block device
From: Tomas_Dalebjörk <tomas.dalebjork () gmail ! com>
Date: 2019-10-25 16:31:25
Message-ID: CACrcyfJE2rEGTVOGTXGTf08w1Z-js8xTRshibCm+PuZNxp3OUA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Wow!
Impressing.
This will make history!
If this is possible, than we are able to implement a solution, which can do=
:
- progressive block level incremental forever (always incremental on block
level : this already exist)
- instant recovery to point in time (using the mentioned methods you just
described)
For example, lets say that a client wants to restore a file system, or a
logical volume to how it looked a like yesterday.
Eventhough there are no snapshot, nor any data.
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.
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.
Do you think that I have understood it correctly?
Den tors 24 okt. 2019 kl 18:01 skrev Zdenek Kabelac <zkabelac@redhat.com>:
> Dne 23. 10. 19 v 13:24 Tomas Dalebj=C3=B6rk napsal(a):
> > I have tested FusionIO together with old thick snapshots.
> > I created the thick snapshot on a separate old traditional SATA drive,
> just to
> > check if that could be used as a snapshot target for high performance
> disks;
> > like a Fusion IO card.
> > For those who doesn't know about FusionIO; they can deal with
> 150-250,000 IOPS.
> >
> > And to be honest, I couldn't bottle neck the SATA disk I used as a thic=
k
> > snapshot target.
> > The reason for why is simple:
> > - thick snapshots uses sequential write techniques
> >
> > If I would have been using thin snapshots, than the writes would most
> likely
> > be more randomized on disk, which would have required more spindles to
> coop
> > with this.
> >
> > Anyhow;
> > I am still eager to hear how to use an external device to import
> snapshots.
> > And when I say "import"; I am not talking about copyback, more to use t=
o
> read
> > data from.
>
> Format of 'on-disk' snapshot metadata for old snapshot is trivial - being
> some
> header + pairs of dataoffset-TO-FROM - I think googling will reveal coup=
le
> python tools playing with it.
>
> You can add pre-created COW image to LV with lvconvert --snapshot
> and to avoid 'zeroing' metadata use option -Zn
> (BTW in the same way you can detach snapshot from LV with --splitsnapshot
> so
> you can look how the metadata looks like...)
>
> Although it's pretty unusual why would anyone create first the COW image
> with
> all the special layout and then merge it to LV - instead of directly
> merging... There is only the 'little' advantage of minimizing 'offline'
> time
> of such device (and it's the reason why --split exists).
>
> Regards
>
> Zdenek
>
>
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
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/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic