From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B8D0A60C57 for ; Wed, 23 Oct 2019 10:06:43 +0000 (UTC) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E398581F01 for ; Wed, 23 Oct 2019 10:06:41 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id u4so6282529ljj.9 for ; Wed, 23 Oct 2019 03:06:41 -0700 (PDT) MIME-Version: 1.0 References: <909d4cae-ddd2-3951-eee8-8dec8faa6f22@redhat.com> <9e58accdc28692b3c8b2b09f37bce57c@assyoma.it> In-Reply-To: From: =?UTF-8?Q?Tomas_Dalebj=C3=B6rk?= Date: Wed, 23 Oct 2019 12:06:28 +0200 Message-ID: Content-Type: multipart/alternative; boundary="000000000000b6d6c80595911272" Subject: Re: [linux-lvm] exposing snapshot block device Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: Gionatan Danti Cc: LVM general discussion and development --000000000000b6d6c80595911272 Content-Type: text/plain; charset="UTF-8" Many thanks for all the feedback. The idea works for those applications that supports snapshots. Like Sybase / SAP Adaptive Server Enterprise, Sybase / SAP IQ Server, DB2, MongoDB, MariaDB/MySQL, PostgreSQL etc.. Anyhow, back to the origin question: Is there a way how to re-create the cow- format. so that lvconvert --merge can be used. Or by having lvconvert --merge to accept to read from a "cow file" If that would be possible, than instant recovery would be possible from an external source, like a backup server. Regards Tomas Den ons 23 okt. 2019 kl 08:58 skrev Gionatan Danti : > Il 23-10-2019 00:53 Stuart D. Gathman ha scritto: > > If you can find all the leaf nodes belonging to the root (in my btree > > database they are marked with the root id and can be found by > > sequential > > scan of the volume), then reconstructing the btree data is > > straightforward - even in place. > > > > I remember realizing this was the only way to recover a major > > customer's > > data - and had the utility written, tested, and applied in a 36 hour > > programming marathon (which I hope to never repeat). If this hasn't > > occured to thin pool programmers, I am happy to flesh out the > > procedure. > > Having such a utility available as a last resort would ratchet up the > > reliability of thin pools. > > Very interesting. Can I ask you what product/database you recovered? > > Anyway, giving similar ability to thin Vols would be awesome. > > Thanks. > > -- > Danti Gionatan > Supporto Tecnico > Assyoma S.r.l. - www.assyoma.it > email: g.danti@assyoma.it - info@assyoma.it > GPG public key ID: FF5F32A8 > --000000000000b6d6c80595911272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Many thanks for all the feedback.

The idea works for those applications that supports snapshots.
<= div>Like Sybase / SAP Adaptive Server Enterprise, Sybase / SAP IQ Server, D= B2, MongoDB, MariaDB/MySQL, PostgreSQL etc..

Anyho= w, back to the origin question:
Is there a way how to re-create t= he cow- format.
so that lvconvert --merge can be used.
= Or by having lvconvert --merge to accept to read from a "cow file"= ;

If that would be possible, than instant recovery= would be possible from an external source, like a backup server.

Regards Tomas

Den ons 23 okt. 2019 kl 08:58= skrev Gionatan Danti <g.danti@ass= yoma.it>:
Il 23-10-2019 00:53 Stuart D. Ga= thman ha scritto:
> If you can find all the leaf nodes belonging to the root (in my btree<= br> > database they are marked with the root id and can be found by
> sequential
> scan of the volume), then reconstructing the btree data is
> straightforward - even in place.
>
> I remember realizing this was the only way to recover a major
> customer's
> data - and had the utility written, tested, and applied in a 36 hour > programming marathon (which I hope to never repeat).=C2=A0 If this has= n't
> occured to thin pool programmers, I am happy to flesh out the
> procedure.
> Having such a utility available as a last resort would ratchet up the<= br> > reliability of thin pools.

Very interesting. Can I ask you what product/database you recovered?

Anyway, giving similar ability to thin Vols would be awesome.

Thanks.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assy= oma.it - info@assy= oma.it
GPG public key ID: FF5F32A8
--000000000000b6d6c80595911272--