MIME-Version: 1.0
In-Reply-To: <20170208125824.z6h4k3kybfm3npfd@exolobe3>
References: <20170121144532.lxn3alp4he4nvrwy@exolobe3>
 <87shnoapcg.fsf@euler.schwinge.homeip.net>
 <20170208125824.z6h4k3kybfm3npfd@exolobe3>
From: SanskritFritz <sanskritfritz@gmail.com>
Date: Wed, 8 Feb 2017 14:02:30 +0100
Message-ID: <CAExbbMzf0ZeaQEUdC-aZD2NFUNv0utrOd2RmBkJL_TXTzTrtSw@mail.gmail.com>
To: Lars Wirzenius <liw@liw.fi>
Cc: Obnam development <obnam-dev@obnam.org>
Subject: Re: Obnam FORMAT GREEN ALBATROSS status and roadmap
Precedence: list
Content-Type: multipart/mixed; boundary="===============0154928674000949269=="
Mime-version: 1.0
Sender: obnam-dev-bounces@obnam.org
Errors-To: obnam-dev-bounces@obnam.org

--===============0154928674000949269==
Content-Type: multipart/alternative; boundary=001a113f2fc895e2520548047c55

--001a113f2fc895e2520548047c55
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 8, 2017 at 1:58 PM, Lars Wirzenius <liw@liw.fi> wrote:

> On Wed, Feb 08, 2017 at 12:34:07PM +0100, Thomas Schwinge wrote:
> > One idea I just had -- but I don't know if that is feasible to implement:
> > you could (internally!) have obnam "write" both the "current" and the
> > "Green Albatross" formats, and then every "read" operation would read
> > both of them, and compare that they return the same data.  Then have
> > obnam complain if that doesn't match (with the "current" format's data
> > then taking precedence, I think).  Obviously, that will add a lot of
> > overhead for every repository access, but any users willing to take that
> > can then easily help testing the "Green Albatross" format.  But I don't
> > know if the repository abstraction in obnam is sufficiently generic for
> > being able to deal with two underlying repository formats, etc.
>
> I fear it'd make things so slow nobody would actually use this, even
> for testing. It'd mean obnam was making two backups at the same time.
>

You could start two obnam instances parallelly :D

--001a113f2fc895e2520548047c55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Feb 8, 2017 at 1:58 PM, Lars Wirzenius <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:liw@liw.fi" target=3D"_blank">liw@liw.fi</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Feb 08, 2017 at =
12:34:07PM +0100, Thomas Schwinge wrote:<br>
&gt; One idea I just had -- but I don&#39;t know if that is feasible to imp=
lement:<br>
&gt; you could (internally!) have obnam &quot;write&quot; both the &quot;cu=
rrent&quot; and the<br>
&gt; &quot;Green Albatross&quot; formats, and then every &quot;read&quot; o=
peration would read<br>
&gt; both of them, and compare that they return the same data.=C2=A0 Then h=
ave<br>
&gt; obnam complain if that doesn&#39;t match (with the &quot;current&quot;=
 format&#39;s data<br>
&gt; then taking precedence, I think).=C2=A0 Obviously, that will add a lot=
 of<br>
&gt; overhead for every repository access, but any users willing to take th=
at<br>
&gt; can then easily help testing the &quot;Green Albatross&quot; format.=
=C2=A0 But I don&#39;t<br>
&gt; know if the repository abstraction in obnam is sufficiently generic fo=
r<br>
&gt; being able to deal with two underlying repository formats, etc.<br>
<br>
</span>I fear it&#39;d make things so slow nobody would actually use this, =
even<br>
for testing. It&#39;d mean obnam was making two backups at the same time.<b=
r></blockquote></div><br></div><div class=3D"gmail_extra">You could start t=
wo obnam instances parallelly :D<br><br></div><div class=3D"gmail_extra"><b=
r></div></div>

--001a113f2fc895e2520548047c55--


--===============0154928674000949269==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
obnam-dev mailing list
obnam-dev@obnam.org
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org

--===============0154928674000949269==--