<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-01-26 23:43 GMT+01:00 Per Øyvind Karlsen <span dir="ltr"><<a href="mailto:proyvind@moondrake.org" target="_blank">proyvind@moondrake.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>2017-01-16 8:04 GMT+01:00 Panu Matilainen <span dir="ltr"><<a href="mailto:pmatilai@laiskiainen.org" target="_blank">pmatilai@laiskiainen.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 01/16/2017 02:51 AM, Neal Gompa wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
On Sun, Jan 15, 2017 at 11:43 AM, Ralf Corsepius <<a href="mailto:rc040203@freenet.de" target="_blank">rc040203@freenet.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not sure how true it is, but it seems to bear out with the number of<br>
previously BDB users now being LMDB users.<br>
</blockquote>
<br>
<br>
Unless a different DB offers substantial advantages over BDB to RPM, which<br>
does not endanger or destabilize rpm, I do not see any reason to switch<br>
different DB.<br>
<br>
</blockquote>
<br>
BDB 5 isLook unmaintained. There's no one upstream working on it, since<br>
Oracle has moved onto BDB 6. No one wants to use BDB 6. RPM should not<br>
depend on dead software. And there are significant performance<br></span>
advantages to LMDB, according to various benchmarks[1].And LMDB looks<span><br>
like it could enable making the RPMDB to be more resilient[2].<br>
<br>
[1]: <a href="https://symas.com/products/lightning-memory-mapped-database/project-benchmarks/" rel="noreferrer" target="_blank">https://symas.com/products/lig<wbr>htning-memory-mapped-database/<wbr>project-benchmarks/</a><br>
[2]: <a href="https://symas.com/products/lightning-memory-mapped-database/feature-comparison/" rel="noreferrer" target="_blank">https://symas.com/products/lig<wbr>htning-memory-mapped-database/<wbr>feature-comparison/</a><br>
<br>
</span></blockquote>
<br>
Lies, statistics, benchmarks, vendor benchmarks... ditto with feature comparisons.<br></blockquote></span><div><div>That's rather quite controversial claims, care to back them up with some references?</div><div><br></div><div>tyself persponally, I wasn't unable to find anything suggesting what you claim, I would've expected to find there being any discussion on the wikipedia article about it in such case: </div></div><div><a href="https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database" target="_blank">https://en.wikipedia.org/wiki/<wbr>Lightning_Memory-Mapped_Databa<wbr>se</a></div></div></div></div></blockquote><div>Looking at feature of lmdb, wouldn't it be possible provide more reliable rollback support without ie. nofsync use wreaking enitre havoc to transactions and rpmdb?</div><div><br></div><div>Database matters are really the subject which I admit the last amount of insight on related to rpm, but previously rpm's --rollback support was yanked with claims of never working right and more reliable support anyways being superiorly addressed on filesystem level togh ie. btrfs snapshot support, for which AFAIK no support of has even been implemented in higher levels tools as back then suggested and serving for rationale of it's removal.</div><div><br></div><div>While I know of debian implementing btrfs snapshot support in apt, to my understanding it was never actually implemented in any higher level tools, making matters worse, with ie. Fedora even since making xfs their fs of choice, obvious practical difficultues and explainings of why never having been realized arises easily..</div><div><br></div><div>For never having "worked properly", it was working quite well with quite common usage of the urpmi.recover tool offered in mandriva linux implementing  rpm's rollback support, with usage of having been quite common without any known major issues reported against suggesting not working properly enough nor not meeting satisfactory expectations wrt. reliability and functionallity provided.</div><div><br></div><div>After adopting <a href="http://rpm5.org">rpm5.org</a> in cooker, urpmi.recover was revived, with other professional developers deeming it sufficiently satisfying their usage of, with some further new development work taking place, while also work on reintegrating the revived tool of taking place.</div><div><br></div><div>To my understanding lmdb's copy on write semantics should prevent transaction data not written to disk to risk making rpmdb very prone to corruptions by ie. nofsync use with only major reliability concern of being whether transaction logs properly written to disk for which rollback up to the point of is major cause of concern to my understanding..</div><div>Transatction logs not written to disk is AFAIK not something which not even btrfs is being any more immune to implications of than as for anywhere else in general...</div><div><br></div><div>Well. just some thougts on the matter based on my (lack of) understanding, any answers explaining the why's and why not's on the matter would be appreciated. :)</div><div><br></div><div>--</div><div>Regards,</div><div>Per Øyvind</div></div></div></div>